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Some  years  ago,  several  far-seeing  members  of  the  military  services 
and  the  training  equipment  industry  recognized  the  need  for  a  more  effective 
technical  interchange  between  military  procurement  agencies  and  the  industry 
developers  of  training  equipment.  An  annual  Interservice/Industry  Training 
Equipment  Conference  was  established  with  the  help  of  the  American  Defense 
Preparedness  Association  and  the  National  Security  Industrial  Association. 
Over  the  past  five  years,  the  scope  of  this  Conference  has  been  expanded  to 
include  consideration  of  management  issues  and  views  from  the  training  equip¬ 
ment  users  in  the  field,  as  well  as  the  continuing  exchange  of  technical 
Information.  These  annual  conferences  have  been  further  broadened  by  provid¬ 
ing  an  opportunity  for  both  government  and  industry  to  exhibit  their  latest 
innovations  in  the  field  of  training  equipment  and  technology.  Conference 
sites  for  these  expanded  Interservice/Industry  Conferences  have  ranged  from 
Salt  Lake  City,  Utah  to  Orlando,  Florida  and,  this  year,  to  the  Nation's 
Capitol,  Washington,  D.C. 

^  These  Proceedings  of  the  5th  Interservice/Industry  Training  Equipment 
Conference -eoffltinue -fee- present  a  record  of  technology  interchange,  training 
management  issues,  and  user  views  from  what  has  become  the  premier  annual 
military/industry  training  conference.  Key  decisionmakers  at  all  levels  of 
the  government  and  industry  will  be  meeting  again  to  consider  vital  issues 
related  to  the  training  of  our  Nation's  Armed  Forces.  "Increased  Readiness 
Through  Training"  is  the  theme  of  the  1983  Conference,  and  this  can  be  made 
reality  through  the  cooperative  efforts  of  all  government  and  industry 
Conference  participants^ 

Credit  for  success  of  this  year's  conference  must  go  to  the  hundreds 
of  persons  who  have  contributed  so  generously  and  willingly  of  their  time  and 
effort.  Members  of  the  Conference  Committee  have  been  tireless  in  their 
pursuit  of  excellence  and  their  efforts  deserve  the  thanks  of  all  who  are 
privileged  to  attend  this  Conference. 
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A  WIDE  F I  ELI)— OF— VI EW  CHI'  PROJECTION  SYSTEM 
WITH  OPTICAL  F F F DB AC K  FOR  SKI.F  ALIGNMENT 
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ABSTRACT 

Evans  &  Sutherland  has  developed  a  multi-channel  CRT  projection  system. 
This  system  uses  microprocessor  technology  with  optical  feedback  to  provide 
self-alignment  for  color-hue,  intensity,  color-convergence,  geometry,  and 
focus.  By  replacing  drift-prone  analog  correction  circuits  with  digital 
circuits  and  D/A  converters,  system  drifts  are  limited  to  gain  and  offset 
errors.  These  errors  are  optically  detected  and  corrected  in  "real  time"  by 
the  microprocessor.  Geometry  drifts  can  be  detected  and  corrected  to  within 
1/4  of  a  pixel.  Because  this  projection  system  is  CRT  oased,  image  generator, 
lens,  and  projection  angle  induced  distortions  as  large  as  30%  can  be  corrected 
by  the  projector's  digital  electronics.  The  projection  system  self-alignment 
capabilities  together  with  edge  matching  make  possible  the  tiling  of  multiple 
channels.  This  facilitates  improved  brightness  and  resolution  over  wide 
f ields-of-view.  A  six  channel  system,  with  30  degree  by  30  degree  fields- 
of-view  for  each  channel,  using  a  12  toot  radius  screen  of  unity  gain  yields  7 
ft-lambert  brightness  with  better  than  3  arc-minute  resolution.^ 


INTRODUCTION 

Wide  f ield-of-view  projection  systems 
are  an  important  part  of  visual  simula¬ 
tion.  Such  systems  should  provide  wide- 
angle  viewing  of  scenes  without  noticeable 
image  discontinuities  and  should  project 
enough  brightness  and  resolution  for  a 
degree  of  realism.  Other  qualities,  such 
as  ease  of  initial-alignment,  stability 
after  alignment,  geometric  adaptability 
and  ruggedness  are  important  for  a  pro¬ 
jector  to  accomodate  various  applications 
and  endure  the  tortures  of  a  motion 
platform.  We  have  developed  a  multi¬ 
channel  CRT  projection  system  with  these 
qualities.  In  brief,  the  projection 
system  can  do  the  following: 

(1)  Display  a  wide  f ield-of-v iew  due  to 
its  modular  design. 

(2)  Be  initially  aligned  through  a 
computer  terminal. 

(3)  Prevent  color-hue,  intensity,  color- 
convergence,  geometry  and  focus  drifts 
by  keeping  itself  in  alignment. 

(4)  Accomodate  a  wide  range  of  optical  and 
off-axis  projection  distortion. 

(5)  Project  a  bright,  high-resolution 
image . 


The  projection  system  consists  of  a 
correction  electronics  cabinet  (CEC) 
and  several  projector  heads.  The  CEC  is 
located  by  the  computer  image  generator 
(CIG),  and  the  projector  heads  are  mounted 
on  the  motion  platform.  Figure  1  shows 


how  the  CEC  receives  signals  from  the  CIG 
and  sends  signals  to  the  projector  heads 
via  cables.  Small  optical  sensors  are 
placed  on  the  screen  just  outside  the 
f ield-of-view.  These  microprocessor- 
controlled  sensors  provide  feedback 
information  for  self-alignment. 


DRIFT  COMPENSATION 

Analog  circuits  inherently  drift  with 
temperature  and  time.  As  a  result, 
display  devices  utilizing  these  circuits 
must  be  periodically  re-aligned.  Align¬ 
ment  can  be  a  time  consuming  process 
especially  if  there  are  multiple  poten¬ 
tiometers  (some  being  interactive), 
capacitors,  inductors  and  delay  lines  to 
be  adjusted.  Frequent  alignment  proce¬ 
dures  are  expensive  so  drifts  should  be 
minimi  zed . 

A  common  method  of  correcting  geo¬ 
metric  distortion  and  color  m i sconvergence 
in  a  display  is  to  generate  a  correction 
polynomial  that  is  a  function  of  the  x  and 
y  deflection  signals.  Such  a  polynomial 
function  might  have  the  form: 

f(x,y)  =  Offset  +  Ax  +  By  +  Cxy  +  Dx^  + 
Exy<-  +  Fx3  . 

Each  tt nm  of  the  polynomial  is  a  different 
type  of  correction.  For  example:  Cxy  is 
a  keystone  correction  and  Exy?  is  a  pin¬ 
cushion  correction.  The  signal  f(x,y)  is 
summed  with  the  deflection  signal  to  pro¬ 
duce  a  reasonably  converged  and  undis¬ 
torted  image.  Figure  2(a)  shows  how  cor¬ 
rection  terms  such  as:  x,  y,  xy,  x? ,  xy^ 
and  x3  can  be  generated  and  summed 
together  in  the  analog  domain.  When  this 
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Figure  2(a).  Analog  Correction 


approach  is  used,  a  separate  potentiometer 
is  necessary  to  adjust  the  weighting  of 
each  product  term  as  it  applies  to  the 
overall  correction  function.  Because 
these  potentiometer-controlled  circuits 
(which  are  the  terms  of  the  correction 
function)  can  drift  independently,  it  is 
very  difficult  to  determine  and  correct 
dr i f t- induced  errors. 

Digital  generation  of  the  correction 
signal  offers  a  superior  method  of  drift 
control.  Figure  2(a)  and  2(b)  show  analog 
and  digital  techniques  for  computing  the 
correction  function  f(x,y).  By  locking 
various  product  terms  together  in  a 
digital  memory  there  can  be  no  independent 
drift  in  the  product  terms.  This  does  not 
eliminate  drift  completely  since  the 
necessary  d ig i tal- to-analog  converters  and 
analog  amplifiers  still  can  drift,  but  it 
does  simplify  the  problem  because  drift 
can  only  occur  in  gain  and  offset. 

Gain  and  offset  errors  can  be  easily 
detected  and  resolved.  This  is  the 
fundamental  premise  that  permits  a  "closed 
loop"  system  around  drift.  Optical 
sensors  located  on  the  projection  screen 
(or  alternatively  sensors  fiber  optically 
coupled  to  the  CRT  faceplate)  sense  the 
drift  induced  errors.  Figure  3  is  a 
simplified  block  diagram  of  the  hardware 
necessary  to  detect  and  correct  drifts. 

By  "closing  the  loop"  or  feeding  back 
around  the  imagery,  important  visual 
parameters  are  automatically  compensated 
by  the  feedback  electronics.  Good 
edge-matching  between  channel  boundaries 
is  assured  by  controlling  the  color-hue, 
intensity,  and  geometric  alignment  of 
adjacent  channels. 

HARDWARE 

The  cathode-ray  tubes,  the  lenses, 
the  projection  screen,  and  the  electronics 
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Figure  2(b).  Digital  Correction 


of  a  projector  must  carefully  be  con¬ 
sidered  when  designing  a  h  igh-perf ormance 
projection  system. 


Cathode-Ray  Tubes 


The  cathode-ray  tubes  (CRTs)  used  in 
the  projector  heads  were  specifically 
designed  for  high  brightness.  They  have 
seven-inch  faceplates  with  high-brightness 
phosphors.  The  green  phosphor  is  P53,  the 
red  phosphor  is  P56,  and  the  blue  phosphor 
is  similar  to  a  P4  silicate  blue.  The 
tubes  operate  at  a  40  kilovolt  anode  volt¬ 
age  and  use  liquid  cooling  to  allow  con¬ 
tinuous  operation  at  high-brightness  video 
levels.  The  4  mil  maximum  spot  size  can 
comfortably  accomodate  a  1024  line  per 
channel  resolution. 


The  lenses  used  in  the  projector 
heads  have  the  following  properties: 

(1)  Small  and  light  weight  to  minimize  the 
moment-of- i ner t ia  on  a  motion 
platform . 

(2)  More  uniform  brightness  over  the 
entire  aperture  of  the  lens 

to  minimize  intensity  rolloff  at  the 
edges  of  a  projection  channel. 

(3)  1024  raster  line  resolution  over  the 
entire  viewing  area. 

These  parameters  were  intentionally 
designed  into  the  lenses  to  improve  the 
overall  system  performance.  Figure  4  is  a 
photograph  of  one  projection  head  with  the 
lenses  attached. 


3 


Figure  3.  Optically  "Closing  the  Loop"  Around  Drifts 


Figure  4.  Projector  Head  and  Lenses 


Projection  Screen 


The  gain  of  the  projection  screen  has 
an  important  impact  on  overall  system 
performance.  If  the  screen  gain  is  too 
low,  the  projected  images  will  appear  dim. 
If  the  gain  is  too  high,  sensitivity  to 
screen  defects  is  increased  and  the  exit 
pupil  (the  area  from  which  the  image  can 
be  viewed)  becomes  smaller.  Also,  color 
separation  at  the  fringes  of  the  exit 
pupil  may  become  noticeable. 


Wide  f ie ld-of-v lew  screens  are  curved 
to  optimally  direct  the  light  troin  the 
projector  into  the  exit  pupil.  The  radius 
of  curvature  for  this  projector  was  chosen 
to  be  approximately  12  feet.  Twelve  feet 
is  a  trade-off  among  exit  pupil  size 
requirements  (one  or  two  observers),  eye 
accomodation,  acceptable  off-axis  viewing 
distortion,  and  a  size  compatible  with  a 
motion  platform.  A  screen  gain  of  3  was 
selected  as  the  optimal  trade-off  among 
projector  brightness  capability,  cross 
illumination  minimization,  and  reason¬ 
able  screen  surface  tolerances. 

Electronics 


The  electronics  of  this  projector 
combine  a  variety  of  technologies. 

Analog,  digital,  electro-optical  and 
microprocessor  designs  interact  to  form  a 
system  that  can  be  initially  aligned 
through  a  computer  terminal,  keep  itself 
in  alignment  with  optical  feedback  and 
diagnose  its  own  hardware  problems. 

Figure  5  is  a  simplified  system  block 
diagram  showing  how  the  electronics 
interact . 

The  system  electronics  are  physically 
partitioned  into  three  sections:  the 
projector  head,  the  correction  electronics 
cabinet  (CEC),  and  the  CEC  interface  box. 
The  "projector  head"  houses  the  CRTs  and 
lenses.  It  also  contains  the  video,  de¬ 
flection,  and  correction  amplifiers.  The 
"correction  electronics  cabinet"  houses 
the  digital  correction  and  microprocessor 
related  hardware.  The  "CEC  interface  box" 
contains  the  sensor  hardware  for  sending 
feedback  information  to  the  correction 
electronics  cabinet.  It  also  buffers  the 
maintenance  signals  sent  from  the  micro¬ 
processor  to  the  projector  heads. 

The  projector  heads  and  CEC  interface 
box  are  mounted  on  the  motion  platform  and 
the  correction  electronics  cabinet  is 


located  next  to  the  image  generator.  One 
correction  electronics  cabinet  and  CKC 
interface  box  will  support  up  to  eight 
projector  channels. 

Following  is  a  brief  discussion  of 
each  major  section  of  hardware. 

Microprocessor  System 


The  microprocessor  system  operates  in 
one  of  four  modes.  The  first  mode  is  the 
"normal  operating  mode"  in  which  the 
projector  accepts  signals  from  the  CIG  and 
displays  images.  In  this  mode  the  micro¬ 
processor  controls  the  projector's  self- 
alignment  procedures  and  performs  real- 
t  ime  diagnostic  tasks  between  action 
fields.  The  second  mode  is  the  "initial- 
alignment  mode".  In  this  mode  a  user  can 
align  the  projector  from  a  terminal  using 
the  built-in  pattern  generator.  The  third 
mode  is  the  "diagnostic  test  mode".  In 
this  mode  the  host  computer  talks  to  the 
projector  and  executes  board  level  diag¬ 
nostic  tests.  The  fourth  mode  is  the 
"local  system  mode".  In  this  mode  a  ROM 
resident  debugger/operating  system  con¬ 
trols  the  projector.  A  user  can  probe  and 
control  the  individual  sections  of  the 
projection  system  from  a  terminal. 

Digital  Correction  Electronics 


Digital  correction  signals  are 
generated  for  intensity,  geometry,  and 
focus.  The  microprocessor  calculates  what 
the  correction  functions  need  to  be  and 
stores  them  in  the  "correction  memories". 
The  data  in  these  memories  are  operated  on 
by  a  digital  transfer  function  and  fed 
into  digital-to-analog  converters. 

Deflection  Drive  and 

Video  Drive  Electronics 


The  deflection  drive  electronics 
receive  the  horizontal  and  vertical  sync 
signals  from  the  CIG  and  generate  the 
signals  required  to  drive  the  deflection 
amplifiers  in  the  projector  head.  These 
signals  are  digitally  generated  by  a 
"state-machine"  which  is  a  slave  processor 
to  the  microprocessor  system. 

The  video  drive  electronics  receive 
the  video  signals  for  red,  green,  and  blue 
from  the  CIG  and  modulates  them  with  the 
required  intensity  correction  and  edge 
matching  signals.  This  modulated  video 
is  sent  over  cables  to  the  video  ampli¬ 
fiers  in  the  projector  head. 

Projector  Head  Electronics 


The  projector  head  houses  the  video, 
deflection  and  correction  amplifiers. 
These  are  linear  amplifiers  that  only 
drift  in  gain  and  offset.  The  bandwidth 


of  these  amplifiers  varies  depen. unj  on 
the  required  system  resolution. 

Phosphor  protect  circuitry  in  the 
projector  head  senses  the  loss  of  hori¬ 
zontal  or  vertical  sweep,  power  supply 
failures,  and  excessive  anode  current.  If 
such  a  failure  is  detected,  the  beam  cur¬ 
rent  and  the  anode  supply  an3  immediately 
turned  oft  to  prevent  CRT  phosphor  damage. 

The  maintenance  cable  extends  the 
microprocessor  system  into  the  projector 
head.  Memory-mapped  ana log-to-d lg i ta 1 
converters  allow  tests  on  the  analog  cir¬ 
cuits,  and  digital  ports  can  be  accessed 
to  observe  the  status  of  parameters  like: 
phosphor  protect,  high-voltage  and  cable 
continuity.  Also,  vide*)  threshold  (G2) 
and  static  tocus  are  controlled  in  the 
projector  head  digitally  via  this  micro¬ 
processor  interface. 

Feedback  Sensor  Electronics 


Photo  sensors  are  placed  between 
adjacent  channels  slightly  outside  the 
f ield-of-v iew .  These  sensors  are  opti¬ 
mized  in  size  and  sensitivity  to  detect 
sub-pixel  positional  drifts  and  slight 
changes  in  image  intensity.  This  analog 
information  is  converted  to  a  digital 
value  and  read  by  the  microprocessor 
system . 


ALIGNMENT 

There  are  two  types  of  alignment  in 
the  projection  system,  i n i t ia 1-al ignmen t 
(IA)  and  self-alignment  (SA).  Initial- 
alignment  is  the  process  of  converging  the 
projected  image  and  correcting  any  geo¬ 
metric  distortions.  Self-alignment  is  the 
process  by  which  the  system  "closes  the 
loop"  around  important  visual  parameters 
to  prevent  the  projected  image  from 
drifting  away  from  the  initially  aligned 
cond i t ion  . 

Initial  Al ignmen t 


The  projector  is  placed  in  the 
initial-alignment  mode  when  an  interrupt 
command  is  generated  by  the  alignment 
terminal.  The  system  software  will  cur¬ 
rently  support  either  a  Digital  VTIUU 
terminal  or  a  hand-held  Termitlex  HT-W 
terminal.  During  alignment  this  terminal 
is  temporarily  located  on  the  motion 
platform  so  the  user  can  see  the  pro¬ 
jection  screen  while  aligning  the  system. 

With  the  projection  system  in 
initial-alignment  mode,  an  "alignment 
menu"  appears  on  the  terminal.  The 
alignment  menu  is  optimized  for  the  most 
"user  friendly"  interface.  Figure  6  shows 
an  alignment  menu  tor  a  VT10D  terminal. 

The  user  can  select  a  parameter  and  modify 
it  interactively.  The  value  of  the 
alignment  parameters  can  be  observed  by 
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Figure  6.  Initial  Alignment  Menu 


pressing  the  appropriate  keys  on  the 
terminal  keyboard.  "HELP"  and  other 
useful  screen  menus  are  also  provided  to 
simplify  the  alignment  process. 

The  most  significant  feature  of  the 
initial-alignment  control  is  its  program¬ 
mability.  Any  correction  function  that 
can  be  defined  mathematically,  can  be 
implemented  to  facilitate  user  interaction 
during  alignment  for  the  particular  geo¬ 
metry  involved.  As  a  result,  complex 
corrections  such  as  off-axis  and  spherical 
distortion  are  easy  to  contend  with.  The 
time  it  takes  to  align  a  projector  channel 
is  small  because  the  "user  friendly"  ter¬ 
minal  interface  makes  complicated  funct¬ 
ions  easy  to  manipulate.  For  instance, 
compound  terms  can  replace  common  cor¬ 
rection  terms  like:  tilt,  linearity,  and 
keystone.  Quasi-automatic  and  even 
totally  automatic  methods  of  initial- 
alignment  are  possible  extensions  of  this 
technology . 

The  "speed  of  the  microprocessor" 
lets  the  user  observe  real-time  changes  on 
the  projection  screen  as  the  correction 
control  is  manipulated.  For  instance,  if 
a  keystone  distortion  is  to  be  introduced, 
the  user  can  press  an  increment  or  decre¬ 
ment  key  on  the  terminal  and  watch  the 
projected  image  change  smoothly  in  key¬ 
stone,  just  as  though  he  were  turning  a 
keystone  potentiometer.  This  immediate 
visual  feedback  is  essential  tor  a 
workable  human  interface. 


The  projector  utilizes  optical  feed¬ 
back  to  automatically  match  color-hues 
between  adjacent  projector  channels.  The 
user  aligns  one  channel  for  the  desired 
color  tempeature  or  "white  level"  and  the 
microprocessor  sets  the  video  parameters 
of  all  the  other  channels  to  match.  This 
saves  time  on  a  multi-channel  system  since 
only  one  channel  requires  careful  color 
alignment  . 

The  expected  correction  function 
(which  is  the  best  average  correction 
determined  at  the  factory)  can  be  pre- 
loaded  in  the  correction  memories  during 
i ni t ial -al ig nment .  This  expected  cor¬ 
rection  serves  as  the  starting  point,  so 
only  slight  modifications  are  required  to 
achieve  the  final  alignment. 

When  initial-alignment  is  completed 
all  the  alignment  parameters  are  stored  in 
a  non-volatile  memory  and  used  as  a  refer¬ 
ence  by  the  self-alignment  software.  When 
the  projection  system  is  powered  down  and 
then  powered  up  again,  it  can  return  to 
the  latest  initial-alignment  state  by 
retrieving  this  non-volatile  information. 

Se 1 f-Al ignmen t 


When  the  projection  system  is  in  the 
"normal  operating  mode"  self-alignment  is 
continuously  operating.  Self-alignment 
refers  to  the  process  of  optically 
“closing  the  loop"  around  system  drift. 


v.v, 


Drifts  in  color-hue,  intensity,  color- 
conve  r.jence ,  geometry,  and  focus  are 
automatically  detected  and  corrected. 

There  are  three  phases  to  the  self¬ 
alignment  process:  data  collection,  data 
analysis,  and  feedback-correction. 

During  data  collection  the  micro¬ 
processor  controls  the  projection 
of  test  information  (during  vertical 
retrace)  in  the  vicinity  of  the  photo¬ 
sensors.  The  test  data  is  slightly  out¬ 
side  the  f ie ld-ot- v i ew  so  system  users 
won't  notice  it.  Ditterent  types  ot  test 
data  are  used  to  check  for  geometry, 
intensity,  and  focus  drifts.  The 
collected  data  are  stored  tor  data 
analysis . 

During  data  analysis  the  micro¬ 
processor  must  analyze  the  collected 
data  and  determine  what  has  drifted.  It 
also  needs  to  separate  gain  drifts  from 
offset  drifts.  This  is  done  by  comparing 
reference  data  from  initial-alignment  with 
the  collected  data  and  processing  the 
differences.  The  result  is  transformed 
into  a  feedback-correction  signal. 

Once  the  collected  data  are  analyzed 
and  a  system  drift  has  been  identified,  a 
signal  is  sent  to  the  proper  feedback- 
correction  circuit.  This  is  the  final 
step  in  "closing  the  loop".  A  system 
drift  has  been  compensated. 

The  rate  at  which  the  microprocessor 
can  perform  data  collection,  data  anal¬ 
ysis,  and  feedback-correction  must  track 
the  maximum  rate  of  drifts  in  the  system. 
This  system  has  been  designed  to  correct 
for  thermal  and  temporal  drifts. 

"Closing  the  loop"  around  the  real 
visual  scene  instead  of  beam-current  or 
some  other  parameter  has  advantages. 
Phosphor  degradation  is  au toma t ica 1 ly 
compensated  since  the  CRT  phosphor  is 
included  in  the  closed  loop  system.  Also, 
the  color-hue  of  all  the  projector  chan¬ 
nels  can  be  made  uniform  by  monitoring  one 
channel  and  setting  the  other  channels' 
video-parameters  to  match. 

During  self-alignment,  system  drifts 
are  continually  being  corrected.  Because 
of  the  digital  nature  of  the  feedback 
signal,  corrections  will  occur  in  quan¬ 
tized  steps.  The  minimum  size  of  these 
correction  steps  are  selected  so  the  "eye” 
cannot  distinguish  them.  For  geometry  the 
minimum  step  is  +/-  1/8  ot  a  pixel. 

MAINTENANCE 

The  mechanical  packaging  of  the 
projection  system  was  designed  to  permit 
easy  access  to  all  individual  components. 
Boards  in  the  correction  electronics 
cabinet  plug  into  a  backpanel,  and  sec¬ 


tions  ot  f  ti>*  pr  qwt  t  n«-n  :  o  .-  ■■■  ■  : , .  i  s  r  — 
i  /.Oil  to  permit  easy  m.i  l  :i  t  ■  ti.i  .,n: 
rep  1  a come n t  . 

When  tne  pt  O  jeer  ■  >r  is  in  t  tie  ”n  'IT  i! 
operating  mode"  rea  1-t  imo  d  l  a  jn  st  i  t 
(  RTD)  are  being  periori'n-  i.  '!)!••  net  - 
processor  continually  nonit  «rs  every  part 
ot  the  system  tor  hardware  and  software 
problems.  When  a  problem  is  identified  i 
message  is  sent  over  a  serial  interface  t  > 
the  host  computer.  During  real-time  diag¬ 
nostics  the  microprocessor  merely  reports 
problems  and  makes  recommendations  but 
does  not  try  to  discover  the  cause  ot  tin- 
problem.  By  so  doing,  the  operator  can 
decide  whether  to  continue  operation  in  a 
partially  tailed  condition  or  shut  down 
for  repairs. 

If  the  microprocessor  reports  a 
problem  and  a  ha  rdwa  re./sot  t  wa  re  failure  is 
suspected,  the  projector  can  be  placed  m 
the  "diagnostic  test  mode".  In  this  mode 
board  level  diagnostic  programs  are  run. 
The  host  computer  selects  the  tests  by 
sending  messages  over  the  serial  interlace 
to  the  correction  electronics  cabinet. 

The  microprocessor  runs  the  test  and  re¬ 
ports  back  over  the  same  interface 
whether  it  passed  or  tailed. 

SYSTEM  CONFIGURATION 

Figure  7  shows  the  projection  system 
under  development.  This  configuration 
typifies  the  off-axis  spherical  projection 
schemes  that  are  possible.  Six  projector 
channels  are  used  to  fill  a  30  degree 
vertical  by  180  degree  horizontal  field- 
of-view.  The  screen  has  a  yain  of  3  which 
yields  a  nominal  brightness  of  20  foot- 
lamberts.  The  line  resolution  is  approx¬ 
imately  3  arc-minutes. 

CONCLUSIONS 

This  projection  system  represents  a 
viable  approach  tor  solving  the  wide 
f leld-of-view,  h igh- resol u t ion ,  high- 
brightness  projection  problem.  The  wide 
range  ot  distortion  correction  allows  off- 
axis  projection  on  curved  surfaces  and  the 
multiple  channel s. prov ide  h igh- resol ut ion 
and  high-brightness  with  existing  projec¬ 
tion  devices.  The  microprocessor  control¬ 
led  initial-alignment,  self-alignment,  and 
diagnostics  make  such  a  system  opera¬ 
tionally  practical. 
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CLOSING  THE  GAP  BETWEEN  AIRCRAFT  AND  SIMULATOR  TRAINING  WITH 
LIMITED  FIELD -OF -VIEW  VISUAL  SYSTEMS 
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Mike  Fortin,  Manager  of  Data  Base  Engineering.  Rediffusion  Simulation  Incorporated 
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ABSTRACT 

A  limited  field-of-view  (LFOV)  visual  system  for  the  F-15  flight  simulator  (FS)  developed 
and  built  by  Goodyear  Aerospace  Corporation  -  would  greatly  increase  the  already  proven  train 
ing  capability  of  the  FS.  The  current  F-15  FS,  having  no  visual  system,  readily  handles  all  its 
assigned  instrument  and  emergency  procedure  training  tasks.  The  LFOV  system  -  capable  of 
adapting  to  cost  parameters  -  will  enhance  the  overall  training  capability  of  the  F  15  FS  by  add 
ing  out-the- window  visual  cues.  The  overall  training  capability,  particularly  in  the  visual  air- 
to-air  and  air-to-ground  modes,  is  expected  to  be  significantly  improved  by  the  addition  of  the 
LFOV  system.  The  data  base  for  the  LFOV  system  is  intended  to  support  air-to-ground,  air- 
to-air,  and  normal  airfield  operations.  Air  Force  instructor  pilots  will  evaluate  the  LFOV  for  a 
three-month  period  by  following  specific  evaluation  plans  and  by  using  strict  grading  procedures. 


BACKGROUND 

Flight  simulators  have  been  for  many  years  ma¬ 
jor  contributors  to  effective  aircrew  training.  Like¬ 
wise,  it  has  been  recognized  that  the  addition  of  a 
visual  system  to  a  simulator  can  significantly  expand 
the  types  and  increase  the  quality  of  training  sce¬ 
narios.  However,  a  complete  visual  system  which 
offers  total  combat  mission  training  can  be  cost  pro¬ 
hibitive.  A  dedicated  evaluation  of  aircrew  train¬ 
ing  programs  might  discover  it  more  cost  effective 
to  train  some  tasks  in  aircraft  and,  consequently, 
select  a  visual  system  that  may  be  limited  but  which 
fits  both  cost  and  training  parameters. 

A  USAF  Operational  Test  and  Evaluation  (OT&E) 
report^  ^  in  1979  cited  the  lack  of  a  visual  system  as 
being  the  number  one  operational  deficiency /limita¬ 
tion  of  the  F-15  Flight  Simulator  (FS)  -  in  operation 
by  the  Air  Force  for  over  six  years .  Three  years 
before  the  OT&E,  the  need  for  a  visual  system  was 
established  as  an  official  requirement^)  for  the 
F-15  FS.  This  requirement  still  remains  unfulfilled 
because  a  cost-effective  approach  to  visual  system 
attachments  has  not  been  developed. 

In  1978,  it  was  determined  that  a  visual  system 
coming  from  USAF  project  number  2360  would  satisfy 
the  requirements  for  the  F-15  FS.  This  proposed 
visual  system  was  to  provide  visual  cues  necessary 
to  train  the  full  tactical  mission .  Due  to  budgetary 
constraints,  this  project  did  not  meet  its  goal. 

The  Air  Force  restarted  the  effort  in  1982  with 
a  requirement  from  HQ  TACD  to  pursue  acquisition 
of  state-of-the-art  limited  field-of-view  visual  sys¬ 
tems  for  the  A-10,  F-15,  and  F-16  simulators.  This 
requirement  prompted  Goodyear  Aerospace  Corpora¬ 
tion  (GAC)  to  initiate  a  study  to  assist  the  Air  Force 
in  specifying  the  requirements  for  a  LFOV  visual 
system  which  would  satisfy  most  of  the  training  task 
objectives. 

DESCRIPTION  OF  THE  F-15  SIMULATOR 

The  F-15  FS  was  designed  to  support  initial, 
continuation,  and  instructor  pilot  training  associated 


with  the  F-15  weapons  system.  It  provides  training 
in  norma!  and  emergency  systems  operations  in  the 
instrument  flight  regime.  Fully  operational  offensive 
and  defensive  systems  permit  integrated  training 
against  a  variety  of  airborne  and  surface  targets, 
but  only  under  simulated  instrument  flight  condi¬ 
tions.  The  simulator,  designed  and  built  by  Good 
year  Aerospace  Corporation  (GAC).  Akron.  Ohio, 
incorporates  a  five- degree-of- freedom  G-seat.  CI- 
suit,  and  a  wide  variety  of  aural  cues  for  a  realistic 
training  environment. 


ANALYSIS  OF  F-15  TRAINING  REQUIREMENTS 


Training  task  requirements  in  references  1.  2. 
and  4  were  analyzed  in  an  attempt  to  specify  the 
field-of-view  (FOV),  FOV  orientation,  and  other 
characteristics  of  a  LFOV  visual  system  best  suited 
to  satisfy  the  training  objectives  of  the  F-  15  FS. 

The  F-15  FS  OT&E^  is  the  most  authoritative 
signal  source  of  F-15  FS  training  task  requirements . 
listing  99  tasks  covering  transition  and  air-to-air 
phases.  The  F-15  FS  trains  all  60  of  the  99  tasks 
assigned  to  it,  including  cockpit  checks,  engine 
operation,  instrument  approaches,  climbs/descents, 
autopilot  operation,  afterburner  operation,  emer¬ 
gency  procedures,  radar  operation,  armament 
operation,  and  scramble  procedures.  In  addition, 
nine  other  tasks  are  considered  partially  trainable 
in  the  F-15  FS.  The  30  remaining  tasks,  such  as 
taxiing,  takeoffs  and  landings,  overhead  patterns, 
aerodynamic  braking,  basic  fighter  maneuvers, 
attacks  against  bogeys,  formation  flight.  "G"  oxer 
cises,  and  flight  controls,  are  classified  as  non- 
trainable  in  the  F-15  FS,  but  most  of  these  may  be 
come  trainable  with  the  addition  of  a  LFOV  svstem. 


Another  source  of  training  task  requirements  is 
the  combination  of  the  minutes  of  a  LFOV  working 
group  at  Eglin  AFB^)  and  the  LFOV  visual  system 
requirements  document^  .  Most  of  the  tasks  in  this 
combined  list  also  appear  in  the  OT&E  task  list:  how 
ever,  the  combined  list  includes  several  air-to 
ground  tasks  not  found  in  the  OT&E  list. 
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Using  these  references,  it  is  readily  apparent 
that  the  FOV  requirements  for  air-to-air  and  air  to 
ground  tasks  vary  widely.  For  the  majority  of  the 
air-to-air  tasks,  FOV  requirements  are  symmetrical 
in  both  azimuth  and  elevation,  with  FOV  require 
ments  as  high  as  140  degrees  in  elevation  and  2-0 
degrees  in  azimuth.  In  nearly  all  cases,  the  FOV 
requirements  for  the  air-to-ground  tasks  are  skewed 
off  to  one  side,  requiring  about  120  degree  by  20 
degree  azimuth  and  120-degree  elevation.  These 
FOV  requirements  were  calculated  largely  by  geome 
trie  analysis  and  by  recording  canopy  migrations  of 
targets  utilizing  the  F - 1 5  FS  and  experienced  fighter 
pilots.  These  results  do  not  vary  widely  from  results 
of  a  study  done  by  the  USAl'O)  using  the  Simulator 
for  Air-To-Air  Combat  (SAAC)  and  the  Advanced 
Simulator  for  Pilot  Training  (ASPT).  (Table  1.1 


TABLE  1  USAF  FOV  STUDY  RESULTS 


Tusks 

Field  of 
requir 
Azimuth 

view 

•od 

Kiev 

r - 

Azimuth 
Left  |  Right 

1 

Klov.it  inn 
I’p  Down 

Air  to-air 

FOV  (dog)  : 

Low  yo-yo 

S3 

88 

42 

41 

f>S 

Immelmon 

86 

95 

56 

30 

76  19 

Lag  roll 

101 

104 

52 

49 

67  :i7 

Hi  yo-yo 

108 

108 

75 

33 

50  58 

Lead  turn 

163 

132 

86 

77 

71  61 

Quarter  plane 

162 

142 

105 

57 

79  6:i 

Barrel  roll 

299 

142 

161 

138 

94  48 

Air-to-  ground 

FOV  (deg)  : 

10-  deg  dive 

67 

69 

65 

2 

52  17 

15-deg  dive 

87 

114 

74 

13 

61  53 

30 -deg  dive 

76 

97 

71 

5 

57  40 

45-deg  dive 

86 

113 

74 

12 

56  57 

Level 

62 

67 

60 

2 

56  1 1 

10-dog  pop-up 

70 

81 

64 

6 

57  24 

30  deg  pop-up 

96 

122 

79 

17 

73  49 

Display  Type:  •  Real-  Projection  Infinity  Dis 
play  •  CRT  Beam  Splitter  •  Dome  Display 

Image  Generator  Capacity  :  •  Animation  Require 

ments  •  Moving  Target  Requirements  •  Texturing 
Requirements  •  Scene  Detail / Density  Requirements 

•  Shading/Color  Requirements 

Projection  System:  •  Brightness  Requirements 

•  Resolution  Requirements  •  Camera  Models  •  Light 
Spot  Models 

Trainer  Impact:  •  Ingress/Egress  •  Maintc 
nanee  Accessibility  •  Software  Enhancements  •  In 
structor  Station  Considerations  •  Contract  Data 
Requirements 

Data  Base  Development:  •  Level  of  Generic 
Terrain  Detail  •  Size  of  Specific  Terrain  Detail 

•  Level  of  Model  Detail 

Most  pilots  generally  agree  even  the  best  state 
of  the  art  computer  generated  image  (CGI)  visual 
system  is  marginal  in  its  ability  to  present  enough 
scene  detail,  high  resolution,  and  brightness  to 
fully  train  all  air-to-air  or  air-to-ground  training 
tasks.  Therefore,  it  might  be  wise  not  to  sacrifice 
quality  in  these  areas  but  concentrate  cost  savings 
in  the  areas  of  reduced  FOV  and  trainer  impact. 

Consideration  was  given  to  ways  of  reducing  the 
simulated  FOV  to  something  less  than  that  required 
to  satisfy  the  F-15  training  objectives  of  220  degrees 
by  140  degrees.  The  FOV  of  the  motionless  human 
eye  has  a  horizontal  extent  of  about  160  degrees 
and  a  vertical  range  of  70  degrees  downward  and  50 
degrees  upwards.  The  F-15  aircraft  FOV  (Figure  1) 
has  a  maximum  vertical  downward  FOV  of  40  de¬ 
grees  with  an  overall  average  downward  FOV  of 
about  20  degrees.  Based  on  these  conditions,  a 
minimum  desirable  FOV  would  be  about  160  degrees 
azimuth  (oriented  symmetrically  about  the  cockpit 
nose)  and  60  degrees  elevation  (oriented  20  degrees 
down  and  40  degrees  up).  This  FOV  should  be 
adequate  for  general  training  requirements, 
straight-in  approaches,  target  identification,  etc. 
However,  the  primary  area  of  interest  will  often  mi¬ 
grate  outside  this  field-of- view  when  flying  against 
a  specific  or  designated  target,  such  as  executing  a 
basic  fighter  maneuver  (BFM)  against  a  bandit,  a 
pop-up  bombing  run  against  a  ground  target,  or  a 


SELECTING  A  LFOV  VISUAL  SYSTEM 

Based  on  the  above  results  it  would  appear 
that  most  of  the  F-15  training  requirements  are 
within  a  FOV  of  220  degrees  azimuth,  oriented 
symmetrically  about  the  cockpit  nose,  and  140 
degrees  elevation ,  oriented  30  degrees  down  and 
110  degrees  up. 

A  LFOV  visual  system  implies  that  compromises 
will  be  made  in  training  objectives  in  an  attempt  to 
minimize  cost.  In  addition  to  FOV,  several  other 
parameters  -  Display  Type,  Image  Generator  Capa¬ 
city,  Projection  System,  Trainer  Impact,  and  Data 
Base  Development  -  must  be  considered  and  can 
have  a  major  cost  impact  on  the  addition  of  a  visual 
system  to  a  FS  : 

FOV :  •  Size  •  Orientation  •  Different  Orienta¬ 
tions  for  Different  Tasks  •  Ability  to  Dynamically 
Track  the  Area-of-Interest 


Figure  1  F  15  Aircraft  FOV  Plot 


m 


KV. 


I?:- 


circling  approach  to  a  runway.  Since  the  orient  ! 
tion  of  tlio  primary  area  of  interest  relative  to  one's 
own  ship  is  known,  there  are  several  ways  in  which 
the  FOV  area  can  he  supplemented  or  the  effective 
FOV  increased.  A  full  display  dome  provides  the 
maximum  flexibility  for  these  considerations  and 
also  significantly  reduces  trainer  modifications  to 
provide  for  student  ingress/egress  and  maintenance 
provisions.  The  primary  disadvantage  of  the  dome 
display  over  other  types  of  infinity  optics  displays 
is  that  the  real  image  is  focused  at  a  finite  distance 
from  eyepoint. 

One  approach  to  increase  the  effective  LFOV 
area  without  adding  CGI  data  channels  is  to  dynam¬ 
ically  track  the  primary  area  of  interest  by  skewing 
the  projectors  to  keep  the  simulated  FOV  area  in 
the  pilot's  line  of  sight  (Figure  2).  For  this  to  be 
practical,  it  is  essential  the  projector  displacement 
mechanism  is  simple  and  the  projector  movement  does 
not  cause  distortion.  As  can  be  seen  in  Figure  2, 
if  the  projectors  arc  mounted  symmetrically  on  a 
horizontal  platform,  the  platform  can  be  rotated 
horizontally  about  the  center  of  the  dome  without 
causing  distortion.  The  vertical  rotation,  however, 
is  a  more  complex  operation  .  Each  projector  must 
be  moved  independently  of  the  other  to  prevent 
distortion . 


Figure  2  -  Typical  Dome /Projector  buyout 


Another  approach  for  more  effective  use  of  a 
LFOV  visual  scene  is  to  manually  reposition  the  pro 
jectors  as  a  function  of  the  training  task.  For 
example,  based  on  the  FOV  study  done  by  the  Air 
Forced),  the  FOV  required  for  most  air-to-air 
maneuvers  is  nearly  symmetrically  in  the  horizontal 
but  the  FOV  is  offset  to  one  side  for  most  air -to- 
ground  tasks. 

Possibly  the  lowest  cost  and  most  desirable 
approach  to  increasing  the  effective  LFOV  area  with¬ 
out  adding  more  CGI  channels  is  the  use  of  a  single 
light  spot  projected  on  the  display  surface.  A  sim¬ 
ple,  low-cost  light  spot  projector  (Figure  2)  and 
associated  host  computer  software  could  determine 
when  and  where  the  primary  area  of  interest  (tar 


Figure  3  -  Light  Spot  Projector 

get,  approach  end  of  runway,  etc.)  is  about  to  mi 
grate  outside  of  the  simulated  LFOV  area.  At  that 
time  and  location,  the  light  spot  appears  on  the  dome 
surface,  allowing  the  pilot  to  continue  tracking  the 
target  movement  until  it  returns  within  the  simu¬ 
lated  LFOV  CGI  visual  scene. 

Determination  of  the  required  image  generator 
(IG)  capacity  (its  ability  to  generate  realistic 
images,  moving  targets,  and  special  effects)  can 
best  be  accomplished  by  developing  tactical  mission 
scenarios  based  on  specific  training  objectives  and 
requirements.  A  typical  mission  scenario,  based  on 
F-15  simulator  training  requirements,  might  consist 
of  three  groups  of  four  F-15  aircraft  in  the  air 
superiority  role,  a  large  number  of  F-4,  A  7.  and 
F-16  aircraft  in  the  strike  role,  a  group  of  four 
enemy  aircraft,  air-to-air  and  surface-to-air  mis¬ 
siles.  moving  ground  targets,  and  antiaircraft  (AAA) 
fire.  The  total  number  of  moving  objects  (aircraft, 
missiles,  ground  vehicles)  within  the  simulated  LFOV 
area  and  within  visual  range  will  be  considerably 
fewer  than  the  total  available  at  any  given  time.  To 
simulate  this  scenario,  the  IG  must  be  capable  of 
handling  between  five  and  ten  moving  targets.  In 
addition  to  the  moving  targets,  the  IG  must  be  cap 
able  of  generating  special  effects  such  as  exploding 
targets,  AAA  tracers  and  flak,  and  smoke  trails  and 
launch  flashes  of  missiles.  These  effects  are  impor 
tant  training  aids  because  they  provide  immediate 
feedback  to  the  student  indicating  performance. 

Till-:  F-15  SIMULATOR  VISUAL 
K VALUATION  SYSTEM 

Because  of  the  subjective  nature  of  many  of  the 
parameters  associated  with  a  LFOV  visual  simulator 
system,  actual  training  effectiveness  evaluations 
can  only  be  accomplished  through  the  use  of  expo 
ricnccd  pilots  practicing  training  tasks  on  a  LFOV 
visual  simulator  system.  A  LFOV  visual  system  will 
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be  integrated  with  an  F-15  FS  and  evaluated  prior 
to  the  FS's  delivery  to  the  Air  Force  in  July  1984. 
This  effort  will  he  undertaken  by  GAC  in  conjunc¬ 
tion  with  Kediffusion  Simulation  Incorporated  (RSI) 
and  Evans  and  Sutherland  (E&S).  A  four-channel 
CGI  CT-5A  visual  system,  with  a  20- foot  display 
dome  and  a  FOV  of  100  degrees  in  azimuth  by  00 
degrees  in  elevation,  will  be  used  for  the  demonstra 
tion.  The  projectors  will  be  mounted  on  a  platform 
which  can  be  manually  repositioned  to  orient  the 
azimuth  FOV'  from  100  degrees  right  and  00  degrees 
left  to  100  degrees  left  and  60  degrees  right.  A  light 
spot  projection  system  will  also  be  used  to  extend  the 
FOV  of  the  primary  area  of  interest  (Figure  4).  The 
visual  data  base  will  encompass  an  area  of  about 
90,000  sc),  nm.  System  development  began  at  GAC 
in  Akron,  Ohio,  January,  1983,  and  the  system  will 
be  turned  over  to  the  Air  Force  for  evaluation  for 
a  three-month  period  beginning  January .  1984 
( Figure  5)  . 


□  LIGHT  SPOT  TARGET  AREA 
H  CGI  LF0V  AREA 
■  EXTEN0ED  LF0V  AREA 

Figure  4  -  Demonstration  System  FOV  Plot 


Figure  5  -  F-15  Visual  Evaluation  Schedule 


LFOV  EVALUATION  DATA  BASE 

The  data  base  for  the  LFOV  simulator  demon¬ 
stration  is  intended  to  support  air-to-air.  air  to- 
ground,  and  normal  airfield  operations.  Due  to  this 
wide  variety  of  tasks,  very  few  of  the  conventional 
trade-offs  were  made  because  the  same  data  base 
must  support  the  entire  flight  regime.  For  example. 


a  strictly  air-to-air  simulator  would  not  require  as 
much  detail  in  the  data  base  to  support  flight  below 
about  5.000  feet  nor  would  an  air  to  ground  siaul.i 
tor  require  flight  above  5.000  feet. 

Even  during  the  short  time  frame  allowed  to 
generate  the  data  base.  Air  Force  personnel  were 
utilized  in  the  process  to  ensure  the  final  data  base 
would  address  the  questions  of  the  evaluation.  Input 
from  aircrews  was  particularly  helpful  and  important 
in  highly  subjective  areas,  such  as  weapons  effects 
where  photographic  documentation  is  very  limited. 
The  success  of  this  interaction  suggests  that  parti 
cipation  by  aircrews  should  be  encouraged  to  an 
even  greater  level . 

AIR  TO  GROUND  CONSIDERATIONS 

The  ground  attack  mission  will  include  low-level 
navigation,  threat  avoidance,  and  low  altitude  deliv 
cry.  as  well  as  the  more  conventional  dive-bomb 
delivery.  To  support  the  navigational  portion  of  the 
flight,  a  100-by-20  nm  corridor  of  "real  world"  in¬ 
formation  is  provided.  The  corridor  begins  at  the 
Seymour- Johnson  AFB  and  ends  at  the  Dare  County. 
N.C..  practice  bombing  range  (Figure  fi).  Because 
this  entire  area  is  relatively  flat,  a  region  of  ge 
neric  hills  has  been  added  to  the  north  of  the  corri¬ 
dor.  These  hills  (Figure  7)  are  intended  to  eval¬ 
uate  the  system’s  capabilities  for  following  visual. 


Figure  6  -  Dare  County  Practice  Range 


Figure  7  Generic  Hills 
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Figure  8  -  Tactical  Target  Range 


terrain.  Also,  near  the  southern  edge  of  the  corri¬ 
dor,  a  large  number  of  tactical  targets  and  threats 
have  been  placed  near  Washington,  N  ,C  .  (Figure  8). 
These  include  fixed  features  such  as  an  airport, 
bridges,  factories,  and  SA-2  sites,  as  well  as  tac¬ 
tical  features  such  as  tanks,  trucks,  ZSU-23/4  anti¬ 
aircraft  guns,  and  SA-6  units  (Figure  9).  A  rail¬ 
road  train  and  a  patrol  boat  on  a  nearby  river  inlet 
will  be  dynamic  targets. 

Possible  exercises  for  evaluation  include  a  low- 
level  mission  from  Seymour-Johnson  AFR  to  an  inter¬ 
cept  point  near  the  practice  range  and  various  at¬ 
tacks  on  practice  bombing  and  strafing  targets.  Al¬ 
ternately,  the  mission  could  proceed  northward  into 
the  generic  hills  to  a  recognizable  turnpoint,  then 
southeasterly  into  the  corridor  where  a  road/rail¬ 
road  intersection  could  be  the  intercept  point  for  an 
attack  on  one  of  the  hard  targets  -  airport,  bridge, 
or  factory .  This  attack  could  then  be  followed  by 
targets  of  opportunity  in  that  same  area.  Both  of 
these  scenarios  could  include  a  return  to  base 
navigation  task . 


AIR-TO-AIR  GAM  ISO  AREA 

The  area  around  the  corridor  will  be  made  up  of 
generic  terrain  approximately  300  -by-300  nm.  This 
means  that  a  small  number  of  terrain  blocks  will  be 
used  over  and  over  to  provide  ground  information 
(primarily  for  the  air-to-air  missions).  These  terrain 
blocks  will  closely  match  the  corridor  terrain,  and 
the  pilot  will  not  recognize  any  difference  except  that 
he  no  longer  has  map  correlation.  The  eastern 
coastline  will  be  included  to  provide  a  course  navi¬ 
gation  and  orientation  cue.  In  actual  simulator  ap 
plication  the  entire  gaming  area  would  probably  have 
real  world  correlation.  For  the  evaluation,  however, 
the  time  constraints  limit  the  amount  of  real  world 
modeling. 

The  air-to-air  targets  include  both  friendly  and 
enemy  aircraft.  The  F-15  is  considered  a  formation 
lead  ship  and  is  modeled  in  high  detail  (Figure  10). 
This  detail  includes  formation  lights,  markings,  mov¬ 
able  wheels,  and  speed  brake.  Also,  a  transparent 
canopy  and  selectable  afterburner  are  depicted.  The 


Figure  9  -  Enemy  Ground  Missile  Sites 


Figure  10  F  15  head  Aircraft  Model 


other  aircraft  are  part  of  the  various  air  to  air  mis 
sions  and  are  modeled  at  a  lower  level  of  detail  more 
atuned  to  the  normal  viewing  range.  These  aircraft 
will  also  have  selectable  afterburners  and  wing  post 
tions  where  appropriate  (Figure  11). 

Seymour-Johnson  AFB  is  included  in  the  data 
base  to  support  takeoff  and  landing  maneuvers. 

Each  mission  could  start  and  end  at  the  airbase,  but 
for  the  evaluation  it  may  be  preferable  to  reset  to 
the  beginning  of  a  specific  exercise.  The  airbase 
model  (Figure  12)  will  provide  sufficient  ground 
cues  for  slow -speed  taxi  and  other  ground  maneu¬ 
vers.  Also,  the  system's  normal  range  of  weather 
effects  may  be  invoked  for  instrument  takeoffs  and 
landings.  Alternately,  visual  departures  and  entries 
may  be  made  using  the  surrounding  geographic  fea¬ 
tures  as  landmarks. 


pilot  acceptance.  For  example,  when  an  aircraft  is 
hit  with  an  AIM  7  (Figure  13).  does  the  trainee 
need  to  see  only  an  explosion  (Figure  14)  or  the 
burning  aircraft's  downward  spiral  and  explosion 
on  the  ground?  The  trade1  offs  made  for  the*  pur 
pose  of  the  LFOV  evaluation  were  also  affected  by 
the  short  time  involved.  Different  choices  may  be 
made  in  an  actual  application  of  the  system. 

Most  of  the  special  effects  use  the  CTaA's  uni 
niation  capabilities.  This  allows  very  realistic 
images  of  dynamic  situations  such  as  a  SAM  launch 
(Figure  15)  or  bomb  explosion.  This  technique 


SPECIAL  EFFECTS 

A  large  part  of  the  data  base  effort  for  the  LFOV 
demonstration  has  been  the  creation  of  special 
effects.  These  generally  include  scenario  compo¬ 
nents  which  cannot  be  handled  with  normal  polygon 
modeling  techniques.  Air-to-air  missiles,  bomb  ex¬ 
plosions,  tracers,  and  antiaircraft  flak  are  a  few 
examples  of  available  special  effects.  These  effects 
usually  add  significantly  to  the  visual  system  and/or 
host  processing  load.  The  degree  of  fidelity  with 
which  they  are  simulated  will  depend  on  a  trade-off 
among  system  capacity,  training  effectiveness,  and 


Figure  13  -  AIM-7 


Figure  11  -  Lower  Level  Detail  Aircraft  Model 


Figure  14  -  AIM-7  Hit  Explosion 


Figure  12  -  Seymour-Johnson  AFB  Model 


Figure  15  SAM  Launch 
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has  the  added  benefit  of  unloading'  the  host  com 
puter.  Only  the  hit  indication  and  a  position  are 
sent  from  the  host  ballistic  program.  The  visual 
then  selects  the  appropriate  animation  sequence . 
moves  it  to  the  given  position,  and  starts  the  se¬ 
quence.  The  animation  sequence  may  cycle  until 
deselected  from  the  host  or  it  may  cycle  only  once, 
requiring  no  further  host  input. 

Another  necessary  visual  effect  for  a  fighter 
simulator  is  the  sun.  No  visual  display  device  will 
provide  the  brightness  associated  with  the  sun  ,  but 
the  gradual  occultation  as  an  aircraft  passes  in 
front  of  it  can  be  simulated  (Figure  910.  In  actual 
training  application,  the  sun’s  interference  with  in 
frared  missiles  should  be  included  in  actual  training 
application . 


Figure  16  -  Aircraft  in  the  Sun 


As  noted  above,  several  more  and/or  different 
data  base  decisions  might  be  required  in  an  actual 
training  application  of  the  system .  It  could  be  more 
mission /aircraft  oriented  for  example.  Also,  the 
inclusion  of  infrared  sensors  in  the  aircraft,  a  re¬ 
quirement  for  radar  correlation ,  and  possible  de¬ 
tached  eyepoint  for  TV  guided  weapons  would  affect 
the  data  base  as  well  as  the  image  generator. 

METHOD  OF  EVALUATION 

A  visual  system  integrated  with  the  F-15  FS  will 
be  evaluated  to  determine  the  training  capability  of 
such  a  system  for  initial  and  operational  training  of 
air  superiority,  air-to-surface  combat,  and  tran¬ 
sition  tasks.  A  listing  of  the  tasks  to  be  evaluated 
is  contained  in  Reference  2.  The  tasks  have  been 
arranged  into  14  separate  missions  designed  to 
evaluate  air  superiority  and  air-to-surface  transi¬ 
tion  training  tasks.  Three  groups  of  evaluation 
pilots,  totaling  48,  will  be  used  in  the  evaluation. 
These  pilots  are  F-15,  F-16,  and  A-10  instructor 
pilots  from  operational  and  training  units.  The  eval¬ 
uation  design  is  shown  in  Table  2. 

The  pilot  groups  are  broken  up  as  follows: 

F-15  Group.  Twenty-four  F-15  pilots  will  serve 
as  evaluation  pilots  and  fly  transition  and  air  super¬ 
iority  missions.  Twelve  F-15  pilots  will  be  from  the 
RTU  environment;  and  the  other  12  evaluation  pilots 
will  be  from  the  operational  training  environment. 


F-16  Group.  Fourteen  F  16  pilots  will  serve  as 
evaluation  pilots  and  fly  transition  and  air  to  surface 
missions  to  evaluate  the  application  of  an  I.FOV 
system  to  train  specific  F-16  training  tasks.  Half 
of  the  F  16  evaluation  pilots  will  be  from  the  RTU 
environment;  and  the  other  half  will  be  from  the 
operational  training  environment. 

A-10  Group.  Ten  A-10  instructor  pilots  will 
serve  as  evaluation  pilots  and  fly  transition  and  air- 
to-surface  missions  to  evaluate  the  application  of  an 
I.FOV  system  to  train  specific  training  tasks.  Half 
of  the  A-10  evaluation  pilots  will  be  from  RTU  en¬ 
vironments;  and  the  other  half  will  be  from  the 
operational  training  environment. 

Prior  to  the  start  of  the  evaluation,  team  mem 
bers  will  receive  training  on  the  system,  practice 
the  evaluation  tasks,  and  make  dry  runs  of  the 
evaluation  procedures.  Subsequent  training  of  new 
evaluation  team  members  will  be  through  on-the-job 
training . 


TABLE  2  -  GENERAL  STRUCTURE  OF  F  -15 
I.FOV  EVALUATION 
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At  the  beginning  of  each  week,  evaluation  pilots 
will  report  to  the  FS  site.  These  pilots  will  be  re 
sponsible  for  rating  the  training  capabilities  of  the 
LFOV  system  and  providing  written  comments  to 
expand  upon  the  ratings.  During  the  initial  in¬ 
briefing,  all  evaluation  pilots  will  be  asked  to  com¬ 
plete  a  F-15  LFOV  background  questionnaire.  Eval¬ 
uation  pilots  will  be  briefed  by  the  project  manager 
on  the  purpose  and  format  of  the  evaluation,  the 
data  collection  form  questionnaire,  the  training 
capability  rating  scale,  factors  that  should  be  con¬ 
sidered  in  the  evaluation  of  tasks,  and  the  specific 
mission.  Briefings  on  subsequent  missions  will  be 
oriented  toward  that  specific  mission . 

After  the  in-brief  has  been  completed,  evaluation 
pilots  will  go  to  the  F-15  FS.  The  evaluation  pilot 
will  sit  in  the  simulator  cockpit  and  will  receive  a 
cockpit /visual  system  familiarization  briefing  by  the 
console  pilot.  For  the  F-15  evaluation  pilots,  the 
briefing  will  be  relatively  short,  concentrating  upon 
the  areas  of  subsystem  differences,  operation,  and 
areas  of  the  simulation  that  need  to  be  addressed 
for  the  evaluation.  The  cockpit  briefing  for  the  F-16 
and  A-10  pilots  will  be  in  more  detail  to  familiarize 
them  with  the  operation  of  the  F-15  weapon  system. 
All  evaluation  pilots  will  use  a  kneeboard  and  attach 
copies  of  the  mission  profile  and  rating  scale  to  it. 

All  other  mission  profiles  and  briefing  guides  arc  on 
file  in  the  project  case  file.  When  the  cockpit  brief 
ing  is  completed  and  all  questions  have  been  an 
swered.  the  console  pilot  will  leave  the  evaluation 
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pijol  in  t!ie  cockpit  and  return  to  the  instructor 
operator  station .  A  simulator  technician  will  assist 
the  console  pilot  in  console  operation  and  data 
collection  as  required . 

Console  pilots  will  be  F-15  pilots  who  have  served 
for  one  week  as  evaluation  pilots.  The  duties  of  the 
console  pilot  will  be  to  manage  each  mission  from  the 
console  and  to  maintain  a  log  book.  The  console  pilot 
will  copy  the  task  ratings  and  comments  given  by  the 
evaluation  pilot,  will  debrief  the  evaluation  pilot  at 
the  end  of  each  mission,  and  will  insure  that  ques¬ 
tions  are  clearly  and  completely  answered. 

The  first  mission  for  all  evaluatio?i  pilots  will  be 
for  the  purpose  of  familiarization  and  warm-up  prac¬ 
tice .  This  familiarization  mission  will  oidy  be  used 
on  the  first  day  of  the  evaluation  week.  During  the 
familiarization  mission,  communication  procedures 
will  be  practiced  and  the  evaluation  pilot  will  famil¬ 
iarize  himself  with  the  FS  operation.  When  the  con¬ 
sole  pilot  is  satisfied  that  the  evaluation  pilot  is 
familiar  with  the  FS,  the  evaluation  will  begin. 

The  console  pilot  will  set  the  simulator  to  a  pre¬ 
selected  set  of  flight  conditions  or  initialize  the 
simulator  for  the  task  to  be  flown.  Initial  conditions 
for  the  initial  task  of  each  mission  will  be  prepro¬ 
grammed  to  preclude  accidental  insertion  of  erroneous 
conditions.  Initial  conditions  for  subsequent  evalua¬ 
tion  tasks  of  a  mission  will  be  manually  set  in  by  the 
console  technician. 

During  each  mission,  the  evaluation  pilot  will 
perform  each  maneuver/task  once  in  order  to  eval¬ 
uate  the  training  capability  of  the  LFOV.  Upon  com¬ 
pletion  of  each  task,  the  evaluation  pilot  will  be  asked 
to  provide  a  rating  of  training  capability  using  the 
rating  scale.  Evaluation  pilots  will  rate  the  training 
capability  of  the  LFOV  system  in  their  area  of  exper¬ 
tise,  i.e.,  RTU  or  operational  training  environment. 
Comments  on  these  ratings  will  be  made  as  appropri¬ 
ate.  If  necessary,  and  at  the  request  of  the  evalua¬ 
tion  pilot,  the  task  may  be  reflown  in  order  to  rate 
and  comment  upon  the  task .  The  console  pilot  will 
transcribe  the  ratings  and  comments  concerning 
factors  that  impacted  the  training  capability  rating 
(e.g.,  field  of  view  limitation  impacts,  brightness, 
visual  system  integration  with  the  F-15  FS,  resolu¬ 
tion  ,  etc . ) . 

The  console  pilot  will  initialize  the  FS  for  the 
next  evaluation  task,  and  the  evaluation  pilot  will 
fly  the  next  task.  This  method  will  be  followed  for 
all  tasks  to  be  evaluated  during  the  mission . 

When  the  last  task  in  each  mission  is  completed . 
the  console  pilot  will  freeze  the  simulator  and  obtain 
the  ratings  and  comments  for  the  last  task.  The 
evaluation  pilot  will  then  egress  from  the  cockpit  and 
will  proceed  to  a  debriefing  area  accompanied  by  the 
console  pilot . 

Another  evaluation  pilot  and  another  console  pilot 
will  be  brought  to  the  FS  area  by  the  program  man¬ 
ager.  The  new  evaluation  pilot  will  sit  in  the  cockpit. 
The  new  console  pilot  will  brief  the  new  evaluation 
pilot  on  the  cockpit  and  the  simulator  operation.  The 
familiarization  part  of  the  mission  will  then  begin  for 
the  new  evaluation  pilot . 


In  the  meantime,  the  evaluation  pilot  who  has 
completed  a  mission  will  be  given  the  data  collection 
form  with  his  task  ratings  and  comments  for  review, 
revision,  and  expansion.  Any  comments  not  put  on 
the  data  collection  forms  will  be  recorded  in  the  eon 
sole  pilot's  log.  This  general  method  will  lie  followed 
for  each  evaluation  pilot  for  all  missions. 

The  overall  training  effectiveness  of  the  visual 
system  for  each  training  phase  will  be  appraised  by 
the  aggregate  of  the  results  of  all  subobjectives  listed 
under  each  objective.  The  measures  for  each  indi 
vidual  subobjective  are  stated  with  those  objectives. 
Failure  of  one  or  more  subobjectives  to  meet  the 
criterion  will  not  necessarily  cause  the  operational 
effectiveness  of  the  I;-15  visual  system  for  that 
training  phase  to  be  judged  unacceptable.  Levels  of 
performance  below  the  criterion  and  the  operational 
impact  of  each  such  deficiency  will  be  identified. 
Based  on  the  aggregate  results  of  all  objectives,  a 
judgment  will  be  made  by  the  evaluation  team  as  to 
the  usefulness  of  LFOV  visual  systems  for  F-15.F  Ifi, 
and  A- 10  aircrew  training  devices. 

CONCLUSION 

A  preliminary  analysis  would  indicate  that  even 
though  the  full  aircraft  FOV  is  not  made  available 
to  the  pilot,  a  LFOV  visual  system  for  a  FS  can  still 
be  a  very  cost  effective  training  device.  The  ad¬ 
dition  of  the  LFOV  visual  system  to  the  F  15  FS 
should  increase  the  FS's  capability  to  train  individ¬ 
ual  air-to-air  tasks  such  as  basic  fighter  maneuvers 
(BFM)  or  complex  tactical  scenarios  involving  a 
large  number  of  active  targets,  seven  of  which  may 
be  moving  in  the  visual  scene  at  any  one  time.  High 
resolution  computer  generated  graphic  models  of 
several  different  aircraft  types  should  enhance 
threat  recognition  training  and  allow  visual  identi¬ 
fication  prior  to  weapons  employment.  Pilots  may 
practice  transition  from  weapon  system  displays  to 
visual  acquisition  of  both  air  and  ground  threats. 
Tasks  such  as  night,  weather,  or  low  altitude  air 
combat  maneuvers  should  be  more  safely  trained  in  a 
FS  with  a  LFOV  than  in  an  aircraft.  Maneuvers  may 
be  flown  against  preprogrammed  adversary  motion 
paths  or  against  an  instructor  flown  adversary  air¬ 
craft.  Programmable  SAM  and  AAA  threats,  capable 
of  launching  and  firing,  let  the  pilot  practice  eva¬ 
sive  maneuvers.  Realism  of  weapons  use  is  enhanced 
by  visual  cues  such  as  smoke  trails  and  explosions. 
Pilots  should  be  able  to  maintain  orientation  with 
adversary  aircraft  outside  the  visual  field-of-view  by 
a  way  of  light  spot  projector. 

In  addition  to  air-to-air  tasks,  most  air-to- 
ground  tasks  can  also  be  trained.  Realistic  terrain 
and  ground  target  modeling  allows  low  altitude  navi¬ 
gation  both  to  and  from  the  target  area.  Training 
for  both  conventional  and  tactical  ranges  is  possible. 
Weapons  effectiveness  can  be  evaluated  by  special 
visual  effects,  such  as  bomb  explosion  and  bullet 
impact  animations.  Basic  aircraft  flight  training  is 
enhanced  as  well.  Visual  cues  associated  with  the 
traffic  pattern  can  be  effectively  integrated  into  the 
instruction  process.  Various  weather  and  lighting 
conditions  may  be  created  for  realistic  instrument 
training,  and  formation  flight  with  both  similar  and 
dissimilar  aircraft  may  be  practiced. 
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ABSTRACT 

In  order  to  meet  user  requirements,  tradeoffs  are  made  in  the  implementation  of  the  four 
functions  (scene  management,  prioritization,  geometric  processing,  and  video  processing)  that 
comprise  a  digital  image  generation  system  of  the  sort  used  for  flight  training.  This  paper 
discusses  how  different  approaches  to  Image  generator  architecture  affect  the  features 
apparent  to  the  user.  Among  the  architectural  variations  discussed  are  programmable  versus 
pipelined  geometric  processing,  and  four  variations  of  video  processor  (scanline, 
teverse-priority-otdered  frame  buffering,  priority-ordered  frame  buffering,  and  distance 
buffeting).  The  architectures  are  compared  with  respect  to  system  cost,  overload 
sensitivity,  and  the  Implementation  of  anti-aliasing,  texture,  and  ttanslucency  features, 
among  others.  Understanding  the  tradeoffs  involved  will  help  designers  and  users  better  meet 
the  requirements  of  a  training  task. 


SPECIFICATION  AND  DESIGN  OF  IMAGE  GENERATORS 


Visual  Image  generators  are  used  to 
synthesize  scenes  which  respond  In  real  time  to. 
typically,  control  inputs  of  a  pilot  In  a  flight 
simulator.  The  image  generators  discussed  in 
this  paper  use  digital  electronics  to  generate 
signals  to  drive  a  raster  display,  usually  a 
cathode  ray  tube  or  a  light  valve  projector. 
Because  the  displayed  scene  must  respond 
Interactively  to  the  control  Inputs,  new  Images 
must  be  generated  30  to  60  times  per  second. 

This  requirement,  together  with  the  required 
resolution  and  scene  detail  of  the  Images,  leads 
to  the  development  of  Image  generators  which  are 
large,  complex  electronic  systems. 

The  functions  performed  by  the  image 
generator  In  making  a  scene  may  be  grouped  Into 
four  categories:  scene  management , 
prioritization,  geometric  processing,  and  video 
processing.  The  scene  management  function  is  the 
process  of  collecting  the  mathematical 
descriptions  of  the  objects  to  be  used  In  the 
scene,  a  process  which  usually  starts  by  data 
retrieval  from  a  disc  storage  device. 
Prioritization  Is  the  determination  of  which 
objects  may  occlude  other  objects  In  the 
generated  Image;  roughly  speaking,  higher 
priority  objects  are  closer  to  the  eyepolnt  than 
lower  priority  objects.  Geometric  processing  is 
the  conversion  of  the  mathematical  descriptions 
of  the  three-dimensional  data  base  objects  Into 
two-dimensional  descriptions  associated  with  the 
coordinates  of  the  display.  Video  processing 
comprises  all  of  the  remaining  steps  needed  to 
define  the  Image  at  each  picture  element  of  the 
display.  Including  the  geometric  subdivision  of 
faces  into  pixels,  detailed  occlusion,  and  the 
generation  of  video  signals  for  the  display. 

There  is  no  single  conventional  architecture 
for  Implementing  the  four  categories  of 
functions,  although  there  are  a  limited  number  of 
approaches  presently  In  use.  The  situation  with 
respect  to  image  generator  architectures  may  be 
contrasted  with  that  of  computers,  for  example. 

In  trtiich  nearly  all  of  the  systems  produced  are 


refinements  of  one  basic  architecture.  Having  no 
conventional  architecture  for  image  generation 
systems  Is  a  situation  with  Implications  for  both 
the  user  and  the  designer. 

Ideally,  the  user  would  not  need  to  know  how 
system  functions  are  implemented.  Instead,  the 
user  might  prefer  to  just  know  the  features  of 
the  system,  l.e.,  what  the  system  does,  not  how 
it  does  It.  Unfortunately,  performance  limits  In 
present  Image  generators  are  too  great  to  permit 
a  simple  specification  like  "Images  shall  be 
indistinguishable  from  the  real  world",  and  every 
attempt  to  write  a  specific  detailed 
specification  runs  the  risk  of  using  terms  or 
concepts  which  ate  Inapplicable  to  the 
architecture  and  set  of  features  of  a  particular 
design.  For  example,  specifying  the  capability 
of  a  system  to  produce  edges  will  cun  Into 
problems  in  systems  designed  with  limits  on  a 
polygon  basis,  or  which  make  use  of  texture  or 
curved  surfaces. 

Fcom  the  designer's  viewpoint,  the  situation 
would  be  simplified  If  there  were  simple  common 
measures  of  performance.  In  the  real  situation, 
there  are  innumerable  tradeoffs  among 
architectures  and  features.  The  "correct" 
tradeoffs  depend  upon  the  intended  application. 
Every  product  designer  must  be  aware  of  the 
requirements  of  the  intended  user  of  his  product, 
but  the  complexity  of  the  product  and  the 
subtlety  of  the  tradeoffs  make  this  task 
especially  difficult  in  the  case  of  Image 
generators. 

This  paper  discusses  some  of  the  fundamental 
tradeoffs  involved  in  designing  an  image 
generator  to  provide  certain  features  to  meet  the 
user's  needs.  To  limit  the  scope  of  the 
discussion,  only  the  top  level  of  Image  generator 
design  is  discussed,  and  then  for  only  a 
restricted  number  of  the  most  popular 
variations.  The  features  discussed  are  limited 
to  a  few  of  the  most  architecturally  Interesting, 
but  Include  both  Image  related  features,  such  as 
capabilities  for  textured  and  translucent  objects 
in  the  scenes,  and  application  related  features, 
such  as  system  cost  and  overload  conditions. 
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SCENE  MANAGEMENT  AW)  PRIORITIZATION 


S vs tea  Functions 

Scene  management  and  prioritization 
functions  are  often  performed  concurrently  In  a 
general  purpose  computer,  but  the  functions  are 
distinct.  The  Image  generation  for  simulation 
begins  with  an  eyepoint  position  and  direction  of 
view  provided  by  another  computet  In  the 
simulator  system.  The  first  step  In  making  the 
Image  is  to  select  the  objects  that  might  be  In 
view  from  that  viewpoint,  and  this  selection 
process  Is  the  basic  scene  management  function. 
Scene  management  Is  performed  continually  as  the 
viewpoint  changes,  and  the  differences  between 
successive  viewpoints  are  usually  so  slight  that 
the  computation  requirements  and  data  bandwldths 
are  within  the  capacity  of  conventional 
minicomputers.  Similarly,  the  priority  relations 
among  objects  which  determine  occlusion  also 
change  slowly  in  many  applications,  so  it  is 
convenient  to  run  the  prioritization  algorithms 
in  the  general  purpose  computer  as  well. 

The  prioritization  function  Is  distinct  from 
occlusion.  Two  objects  have  a  ptiorlty 
relationship  if  one  may  potentially  occlude  the 
other,  l.e..  if  every  line  of  sight  from  a  given 
viewpoint  will  strike  the  high  priority  object 
before  the  lower  priority  object  whenever  the  two 
happen  to  overlap  in  the  view.  Occlusion  is  the 
precise  determination  of  which  parts  of  each 
object  are  visible  given  the  priority 
relationship.  If  the  objects  interpenetrate  or 
mutually  overlap  no  priority  relationship  of  the 
sort  described  will  exist.  Consequently.  Image 
generators  which  depend  upon  priority  algorlttas 
to  establish  priority  relationships  must  use  data 
bases  meeting  special  conditions.  These 
conditions  usually  end  up  requiring  that  all 
objects  be  subdivided  Into  convex  pieces. 

Systems  using  priority  algorithms  usually 
have  an  architecture  which  feeds  the  results  of 
the  priority  algorithm  Into  the  video  processing 
(Fig.  1).  The  video  processor  takes  the 
two-dimensional  descriptions  of  the  objects,  as 
produced  by  the  geometric  processor,  and  uses  the 
priority  order  to  determine  on  a  picture  element 
(or  finer)  basis  which  portions  of  the  objects 
should  be  displayed. 
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Figure  1.  Conventional  organization  of 
image  generator  functions. 

An  alternative,  however.  Is  to  have  the 
prioritization  performed  In  the  video  processor 
along  with  occlusion  (Fig.  2).  Conceptually, 
this  approach  Is  straightforward;  for  each 
picture  element  the  video  processor  must  decide 
which  face  Is  closer  to  the  viewpoint  and  then 
perform  occlusion  accordingly.  The  distance 
sorting  approach  removes  the  restrictions  on  the 
types  of  objects  In  the  data  base  that  are 


imposed  by  priority  algorithms,  and  it  does  away 
with  the  priority  algorithm  execution.  Despite 
the  conceptual  simplicity  and  flexibility  of 
distance  sotting,  the  cost  of  the  high  speed 
hardware  required  to  do  operations  on  each 
pictute  element,  and  problems  with  picture 
quality  and  translucency  effects,  limit  the 
application  of  the  technique. 
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Figure  2.  Prioritization  performed  with 

video  processing  in  a  distance  buffeted 

architecture. 

If  a  priority  algorithm  approach  is 
selected,  there  ate  circumstances  when  the 
processing  speeds  of  conventional  minicomputers 
may  be  inadequate.  Ordinarily,  objects  change 
ptiorlty  slowly  as  the  viewpoint  moves  in  the 
data  base.  Moving  objects  In  the  data  base 
complicate  the  situation  because  they  must  be 
prioritized  not  only  with  respect  to  each  other, 
but  with  respect  to  the  fixed  objects.  In 
addition  to  running  the  priority  algor itlmr  more 
frequently,  the  real  time  software  may  have  to 
build  mathematical  planes  to  separate  moving 
objects  from  fixed  Objects.  Separating  planes, 
or  other  mathematical  structures  used  by  the 
priority  algorithm,  are  ordinarily  built  off-line 
for  the  fixed  data  base.  Altogether,  Increased 
processing  requirements  may  requite  a  more 
powerful  computer  or  special  purpose  hardware  to 
execute  the  algorithms. 

Scene  management  functions  may  also  tax  the 
capacity  of  minicomputers.  Ordinarily,  the 
viewpoint  changes  relatively  slowly,  as 
determined  by  the  motions  of  the  vehicle  being 
simulated.  Consequently,  lists  of  data 
potentially  In  view  can  be  updated  rather 
slowly.  If  the  vehicle  can  turn  rapidly  or 
rotate.  It  is  usually  not  a  serious  problem  to 
expand  the  potentially  viewed  area  to  include  a 
wider  margin.  Even  expanding  to  the  whole  sphere 
of  view  may  only  require  a  few  times  as  much  data 
as  the  actual  displayed  portion.  However,  new 
developments  In  display  technology  make  It 
possible  to  concentrate  the  scene  detail  in  an 
"aroa-of-interest"  where  the  person  under 
training  Is  looking.  The  ultimate  in  atea- 
of- interest  displays  Is  an  eye-tracked  system, 
where  scene  detail  Is  concentrated  In  the  high 
resolution  portion  of  human  vision.  This 
approach  avoids  wasting  Image  generation  capacity 
on  portions  of  the  scene  only  peripherally  in 
view,  but  it  also  means  that  scene  management 
must  be  performed  at  rates  compatible  with  the 
very  high  slew  rates  of  the  eye.  As  with 
prioritization,  this  Implies  either  a  more 
powerful  computer  or  specialized  hardware,  or 
both. 


GEOMETRIC  PROCESSING 


In  order  to  show  objects  which  appear 
perspectlvely  correct  from  any  viewpoint, 
processing  must  start  with  a  data  base 
representation  which  gives  a  three-dimensional 
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■odel  of  the  object  to  be  depected.  Most 
conventionally,  the  representation  uses  vertices 
In  rectangular  (x.y.z)  coordinates  to  build 
polygonal  faces  and  polyhedral  objects,  but  the 
surfaces  could  be  described  by  equations  of 
curved  surfaces  or  by  more  general  recursive 
functions.  However  represented  In  the  data  base, 
geometric  processing  Is  performed  to  transform 
the  objects  Into  two-dimensional  representations 
In  the  coordinate  system  of  the  display  screen. 
The  steps  In  this  processing  typically  Include 
translation  and  rotation.  Illumination, 
perspective  division,  clipping  (to  the  screen 
boundaries),  and  computation  of  parameters  needed 
for  later  shading  and  texturing  of  the  surfaces. 

There  ate  two  basic  approaches  to  geometric 
processor  design:  special  purpose  pipelined 
hardware  or  general  purpose  programmable 
hardware.  Until  very  recently,  the  only  feasible 
method  of  achieving  the  required  throughput  was 
to  build  pipelined  hardware  specifically  for  the 
task,  perhaps  with  some  mlcroprogrammable 
processes  embedded  in  the  design.  The  pipelined 
approach  achieves  very  high  throughput,  but  the 
design  is  complex  and  expensive  to  modify.  A 
mote  general  computet  approach  is  now  just 
becoming  feasible  with  parallel  processing  and 
the  use  of  high  performance  VLSI  computing 
elements.  Because  the  development  of  general 
purpose  computing  elements  is  supported  by  a 
broad  market  and  the  Image  generator  market  is 
comparatively  small,  the  economics  of  the 
programmable  approach  will  probably  become  mote 
favorable  with  respect  to  custom  pipeline  designs 
as  time  goes  on.  In  addition,  there  is  the 
inevitable  trend  to  more  complex  geometric 
processing  algorithms  to  support  a  greater 
variety  of  image  features.  This  means  more 
programming  rather  than  more  custom  hardware  when 
the  programmable  approach  is  adopted. 

The  geometric  processing  problem  is  ideally 
suited  to  parallel  processing  because  the  image 
is  built  of  hundreds  or  thousands  of  Independent 
objects.  Nonetheless,  the  computat ional 
requirements  are  formidable,  requiring  roughly  20 
million  floating  point  operations  per  second  and 
perhaps  00  million  bytes  per  second  of  Input  and 
output.  Considering  Just  the  arithmetic 
operations,  about  100  of  the  most  advanced 
microprocessor  arithmetic  units  would  have  to  be 
kept  busy  to  perform  the  calculations.  Spreading 
the  load  evenly  among  so  many  processors  poses 
■any  problems,  but  the  approach  is  near  the 
borderline  of  feasibility  for  devices  as 
expensive  as  image  generators. 


Whether  programmed  or  done  in  special 
hardware,  there  ate  distinct  possibilities  of 
merging  scene  management  and  prioritization 
functions  Into  the  geometric  processing  hardware 
structure,  and  one  of  the  design  tradeoffs  in 
doing  so  is  the  flexibility  of  making  changes 
versus  the  efficiency  of  processing.  (This  Is 
evident  within  the  software  realm  Itself,  as 
well.  The  trend  is  definitely  away  from  writing 
scene  management  software  In  assembly  language 
and  towards  coding  In  high  level  languages.  The 
loss  in  execution  efficiency  Is  now  more  than 
compensated  by  Increased  flexibility  and 
■aintalnabl 1 lty. ) 


Near  the  video  processing  end  of  the 
geometric  processing,  the  principal  design 
tradeoff  is  in  regard  to  system  bandwidth  versus 
load  management  ability.  Image  generators  often 
drive  mote  than  one  display,  so  It  Is  natuial  to 
dedicate  hardwa  .  to  each  display  to  provide 
parallelism  in  che  computations.  However, 
whenever  hardware  is  dedicated  to  a  display,  the 
system  will  have  some  susceptibility  to  overload 
In  one  channel  while  there  is  spate  capacity  In 
another,  an  obvious  Inefficiency.  At  some  point 
In  the  system,  the  bandwidth  of  generated  data 
becomes  too  great  to  permit  Interchange  among 
processors,  but  the  exact  point  is  a  design 
decision.  One  logical  point  to  make  the  division 
is  after  geometric  processing,  but  the  split 
could  be  made  earlier.  In  the  middle  of  geometric 
processing.  The  point  In  the  system  after 
clipping  to  window  boundaries  is  another  logical 
podnt  for  the  split.  In  general,  systems 
dividing  the  data  streams  earlier  will  avoid 
design  problems  of  high  data  bandwldths  within 
the  machine,  but  at  the  expense  of  less 
efficiency  and  greater  overload  susceptibility. 


VIDEO  PROCESSING 


A  general  purpose  computing  approach  may  be 
considered  for  geometric  processing,  but  video 
processing,  with  requirements  hundreds  of  times 
greater,  is  safely  in  the  domain  of  special 
purpose  hardware  for  the  foreseeable  future. 

High  processing  and  data  bandwidth  requirements 
are  Inherent  In  the  generation  of  30  million 
pixels  pet  second  per  channel,  the  result  of 
subdividing  the  displayed  faces  into  picture 
elements.  Each  picture  element  Is  described  by 
three  color  components  which  in  turn  are  affected 
by  smooth  shading,  atmospheric  haze  fading, 
translucency  (which  will  show  the  colors  of 
underlying  pixels) ,  anti-aliasing  (which 
“smooths"  edges),  and  a  variety  of  other  effects. 


Scanllne  Architectures 

One  of  the  original  approaches  to  dealing 
with  so  much  processing  was  to  perform  the 
operations  a  scanllne  at  a  time  In  synchronism 
with  the  raster  display  of  the  scanllries.  This 
approach  Is  now  well  documented  and  has  been  used 
by  most  of  the  image  generator  manufactur lng 
companies.  [1] 

In  order  to  generate  the  data  for  a  given 
line  of  the  display,  the  objects  (or  the  edges  of 
polygonal  faces  forming  the  objects)  must  first 
be  sotted  to  find  those  Intersected  by  the  line. 
The  beginning  and  end  of  each  face  on  the  line  Is 
then  determined,  and  occlusion  performed  using 
the  previously  computed  prioritization.  The 
visible  pieces  of  polygons  are  then  converted  to 
picture  elements  and  displayed. 

It  might  seem  that  the  sotting  process  would 
be  a  principal  drawback  to  the  technique,  but  It 
actually  is  not.  The  sort  Is  Implemented  in 
hardware  that  supports  many  simultaneous 
comparisons,  so  that  the  N  log  N  growth  of 
sorting  times  associated  with  the  sequential 
sorting  of  random  arrays  does  not  apply.  In 
fact,  the  principal  disadvantage  is  that  the 
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entice  processing  operation  is  synchronous  by 
line,  and  hence  the  processing  overload  condition 
will  be  driven  by  the  single  most  complex 
scanilno  in  the  scone.  Consequently,  a  scene 
which  is  sparse  overall  may  nonetheless  overload 
the  system  because  time  spent  on  a  complex  line 
cannot  be  made  up  later  on  empty  lines. 

Buffering  two  or  more  scanlines  alleviates 
the  problem  by  allowing  the  generator  to  run  less 
strictly  in  synchronism  with  the  display.  Once 
it  becomes  economically  feasible  to  buffer  a 
whole  screen,  a  family  of  “frame  buffeted" 
architectures  becomes  possible  that  offers  other 
advantages  in  addition  to  the  elimination  of 
scanllne  overload. 


Reverse-Ptlotlty-Ordeted  Writing 

Rather  than  fill  scanlines  one  at  a  time 
from  the  top  of  the  screen,  a  frame  buffer  allows 
construction  of  the  picture  in  a  number  of 
different  orders,  unrelated  to  scanline 
position.  The  most  conceptually  simple  is  the 
so-called  "painter's  algorithm"  in  which  faces 
are  converted  to  pixels  and  written  into  the 
buffer  in  reverse-priority-order,  i.e.  the  lowest 
priority  faces  are  written  first  and  then 
overwritten  by  higher  priority  faces  to 
accomplish  occlusion.  For  example,  the  sky  would 
be  written  first,  followed  by  the  ground  plane, 
distant  objects,  and  finally  close  objects. 

Note  that  to  accomplish  occlusion  by  this 
method  it  is  necessary  to  generate  every  pixel  of 
every  face,  regardless  of  whether  or  not  any 
portion  of  a  particular  face  is  visible  on  the 
screen.  Thus  if  there  are  a  million  pixels  in 
the  display,  several  times  that  number  of  pixels 
may  have  to  be  generated,  depending  upon  the 
amount  of  occlusion  in  the  scene.  Consequently, 
although  the  generation  of  the  pixels  is 
straightforward,  a  great  deal  of  fast  hardware 
will  be  tequlced.  and  the  system  may  be  subject 
to  overload  under  a  non-intult ive  condition  of 
total  pixel  area  written. 


Priority-Ordered  Writing 

The  overload  due  to  total  writing  can  be 
partially  cured  by  changing  to  the  less 
straightforward  scheme  of  writing  the  highest 
priority  objects  first.  In  this  method  a  mask 
must  be  built  to  keep  track  of  the  portions  of 
the  screen  written  during  the  course  of 
processing.  By  reference  to  the  mask,  which 
could  actually  be  built  hierarchically  with 
blocks  of  bits  corresponding  to  the  pixels  of  the 
display,  succeeding  faces  can  be  checked  for 
occlusion  and  portions  skipped  over  as 
appropriate.  System  complexity  is  Increased  in 
that  additional  logic  is  required  for  the  masking 
and  skipping,  but  the  efficiency  is  also 
increased.  The  processing  of  shading,  fading, 
texturing,  and  the  like  is  avoided  on  occluded 
pixels  in  favor  of  the  simpler  masking  and 
skipping  operations.  If  the  skipping  and  mask 
updating  can  be  accomplished  much  faster  than  the 
processing  of  displayed  pixels,  then  the  system 
will  be  very  robust  with  regard  to  overloads. 


Distance  Buffering 

Both  priority-ordered  and  tevercc-pr lot ity- 
ordered  writing  depend  upon  a  separate 
prioritization  process  to  support  the  video 
processing.  Prioritization  can  be  performed 
concurrently  with  video  processing  by  expanding 
the  dept  of  the  frame  buffer  to  hold  the  distance 
to  the  picture  element  in  addition  to  its  color 
components.  The  objects  may  then  be  computed  in 
any  order  and  the  distances  to  new  picture 
elements  compared  to  those  previously  written. 

At  the  end  of  processing,  the  surfaces  closest  to 
the  viewpoint  at  each  pixel  will  be  represented 
in  the  buffer. 

For  computational  convenience,  the  existance 
to  a  plane  parallel  to  the  screen  plane  may  be 
used  Instead  of  the  true  viewing  distance,  and 
the  reciprocal  of  the  distance  can  be  used  in 
memory  rather  than  the  direct  function.  Systems 
ate  called  “Z-buffered"  rather  than  distance 
buffered  when  the  distance  to  a  plane  is  used. 

Z-bufferlng  has  the  great  advantage  of 
solving  the  priority  problem,  but  it  has  several 
other  drawbacks.  Like  reverse-priority  ordered 
writing,  every  picture  element  must  be  computed, 
even  the  ones  ultimately  occluded.  The  frame 
buffer  must  be  enlarged  to  store  the  distance 
function,  a  disadvantage  that  diminishes  as 
memory  becomes  cheaper.  But  the  most  serious 
disadvantages  lie  in  the  difficulties  with 
anti-aliasing  and  translucency  implementations, 
which  are  discussed  in  the  next  section. 


IMAGE  GENERATOR  FEATURES 

The  features  of  a  system  are  the  elements  of 
its  specification.  These  elements  include 
overload  properties  and  other  applications 
related  characteristics,  and  the  image  quality 
and  types  of  visual  effects  that  can  be 
produced.  There  ate  dozens  of  visual  effects 
that  can  be  itemized  in  an  image  generator 
specification,  ranging  from  color  properties  to 
the  generation  of  landing  light  illumination 
effects.  For  present  purposes  it  is  sufficient 
to  discuss  a  few  of  the  important  features  that 
have  an  architectural  impact  upon  the  system. 


Image  Content 

Ant 1-al lasing.  Aliasing  problems  originate  from 
attempting  to  determine  the  display  of  an  entire 
pixel  based  upon  a  single  sample  point  within  the 
pixel,  or  from  too  few  sample  points  within  the 
pixel.  The  symptoms  of  aliasing  in  an  image  are 
stairstepped  edges,  thin  lines  broken  into  dotted 
lines,  and  discrete  rather  than  continuous  motion 
as  objects  undetgo  transitions  from  scanllne  to 
scan line  when  the  scene  changes. 

Solutions  to  the  aliasing  problem  involve 
either  the  sampling  of  many  points  within  the 
pixel  and  possibly  adjacent  pixels,  and  then 
combining  the  points  in  a  weighted  average  to 
obtain  the  picture  element  color  and  intensity, 
or  treating  the  image  analytically  with  a  similar 
combination  of  weighted  areas  in  the  picture 
element . 


22 


Trans lucencv.  There  are  translucent  objects, 
particularly  smoke  and  clouds,  that  enhance  some 
generated  scenes.  However,  the  principal  use  of 
translucency  Is  to  facilitate  the  change  In  the 
level  of  detail  of  object  models.  To  save 
capacity,  simple  models  can  be  used  for  objects 
ta  the  distance  and  then  replaced  with  more 
detailed  models  as  they  become  closer.  A 
translucency  capability  allows  a  smooth 
transition  among  the  models,  thereby  permitting 
later  transitions  without  the  distraction  of  a 
sudden  replacement . 

Texture.  Texture  Is  a  modulation  of  the  surface 
of  a  generated  object  using  a  hardware  generated 
or  stored  pattern.  The  intensity  of  the  surface 
is  usually  varied  pseudotandoraly  to  give  a 
greater  sense  of  depth  and  apparent  motion  In  the 
image.  Surface  parameters  such  as  color  and 
translucency  can  be  modulated  in  addition  to 
Intensity  to  provide  a  great  range  of  effects. 

An  interesting  special  case  of  texture  is  the 
reproduction  of  digitized  photographs,  perhaps 
Including  translucent  regions,  to  add  realism  to 
the  generated  scene  (Fig.  3.) 


Figure  3.  An  image  with  translucency  and 
texture  effects. 


Smooth  Shading.  Image  generators  designed  to 
work  with  polygons  can  provide  an  illusion  of 
smoothly  curved  surfaces  by  shading  the  objects 
as  if  they  were  curved.  The  smooth  variation  of 
Intensity  used  for  smooth  shading  can  be  extended 
to  smooth  variation  of  color  or  translucency  In 
the  same  manner  in  which  texture  was  extended  fot 
these  parameters. 

Curved  Surfaces.  Curved  surfaces  may  be 
approximated  by  polygons,  but  special  hardware 
can  also  be  provided  to  generate  the  surfaces 
from  a  few  parameters.  Because  polygon 
processing  is  so  straightforward,  especially  in 
video  processing,  it  is  debatable  whether  less 
hardware  is  needed  to  directly  generate  complex 
curved  surfaces  rather  than  generating  them  by 
polygons,  but  curved  surfaces  clearly  provide  for 
a  more  compact  data  base  representation  of 
objects  that  are  Inherently  curved. 


System  Features 

The  remarks  regarding  the  variety  of  visual 
effects  also  apply  to  the  profusion  of  other 
system  features.  Three  of  the  most  important  are 
discussed  here. 

Overload  Resistance.  All  systems  have  finite 
processing  capacity,  but  all  of  the  elements  of 
the  system  should  be  well  balanced  so  there  ate 
no  critical  bottlenecks.  The  capacity  of  the 
system  should  be  as  large  as  possible  within  the 
cost  constraints,  and  there  should  be  graceful 
overload  and  recovery  characteristics. 

Modular  Const  ruction.  Presently,  there  is  no 
choice  but  to  make  image  generators  large  and  to 
some  degree  complex,  but  many  of  the  problems  of 
large  systems  can  be  minimized  if  the 
architecture  is  highly  regular.  The  "modularity" 
of  a  system  may  be  quantified  as  the  ratio  of  the 
number  of  circuit  cards  in  the  system  to  the 
number  of  types  of  cards  in  the  system.  High 
modularity  is  desirable  because  it  helps 
production  economy,  simplifies  training  of 
maintenance  personnel,  and  minimizes  the  spare 
parts  requirements.  The  greater  the  modularity 
number,  the  greater  the  benefits. 

Another  reason  for  desiring  a  highly  regular 
architecture  is  that  it  eases  the  transition  to 
increased  use  of  large  and  very  large  scale 
integration.  The  development  of  custom 
integrated  circuits  is  mote  easily  amortized  if 
they  are  used  repeatedly  within  the  system. 


Configurability.  Designing  an  image  generator 
from  scratch  is  too  lengthy  and  expensive  a 
process  to  be  undertaken  for  every  new 
application.  Consequently,  it  is  desirable  to 
design  systems  which  are  adaptable  in  terms  of 
capacity  and  features  so  as  to  fit  as  wide  a 
range  of  applications  as  possible.  This  also 
provides  a  growth  path  for  the  user  should  his 
requirements  change. 

Making  a  system  reconf igutable  by  capacity 
is  generally  more  consistent  with  high  modularity 
than  making  it  reconf lgurable  by  feature. 
Nonetheless,  features  which  involve  substantial 
amounts  of  hardware,  such  as  curved  surface 
generation,  are  candidates  for  design  as  options. 


ARCHITECTURE  CONFLICTS  WITH  FEATURES 


Obstacles 


Some  architectures  lend  themselves  better  to 
the  implementation  of  certain  features  than  do 
others.  Rarely  are  the  obstacles  theoretically 
Insurmountable,  but  practical  system  cost  and 
complexity  may  be  unacceptable  unless  a  clever 
Innovation  is  found  to  resolve  the  potential 
Incompatibility.  The  resolution  of  the  problem 
may  take  the  form  of  a  restriction  of  the  system 
capability,  the  use  of  an  approximate  rather  than 
exact  method,  or,  ultimately,  the  exclusion  of 
the  feature  in  favor  of  others  more  compatible 
with  the  architecture  and  more  important  in  the 
Intended  application. 
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Scan line  Architectures 


The  major  problem  of  scanline  architectures 
Is  the  Intersection  overload  problem  previously 
discussed.  There  are  other,  more  minor,  problems 
related  to  the  maintenance  of  a  stack  of 
scanstrlpe  segments  and  the  resolution  of 
overlaps  and  translucent  objects  in  the  stack. 

The  algorithms  for  resolving  all  of  the  occlusion 
analytically  on  a  subpixel  basis  lead  to  complex 
hardware. 

Nonetheless,  a  very  general  technique  for 
"modularizing''  a  video  processor  architecture 
applies.  If  work  is  to  be  shared  among 
processors,  it  is  better  to  share  it  by 
alternating  among  pixels  or  scanlines  than  to 
subdivide  the  screen  into  regions.  The  loading 
is  much  mote  likely  to  be  even  if  the  load  is 
shared  as  suggested.  In  the  scanline 
architecture,  it  is  better  to  have,  for  example, 
one  processor  do  the  odd  scan lines  and  the  other 
the  even  scanlines  (in  a  field)  than  to  have  one 
do  the  tight  half  and  the  other  the  left  half  of 
the  screen.  If  the  screen  is  dedicated  by 
halves,  an  overload  may  occur  if  the  scene 
complexity,  perhaps  the  airport  in  a  flight 
simulation,  happens  to  fall  predominately  in  one 
half. 

The  reverse-priority-ordered  writing  problem 
of  having  to  write  every  pixel,  whether  occluded 
or  not.  is  partially  offset  by  the  relative 
simplicity  of  the  approach.  General  ttanslucency 
is  Implemented  straightforwardly  by  mixing  a 
portion  of  the  underlying  color  and  intensity 
with  the  new  object.  Anti-aliasing  can  be 
performed  by  accounting  for  the  fraction  of  the 
area  in  the  picture  element  being  covered,  and 
mixing  according  to  the  fraction;  the 
anti-aliasing  can  be  done  over  a  larger 
convolution  base  with  a  weighted  function  if 
required. 

The  most  difficult  problem  with  this  method 
arises  from  occlusion  not  being  performed  on  a 
subpixel  basis.  Consider  a  mountain  made  of 
green  poloygonal  faces  silhouetted  against  a 
bright  sky.  The  sky  would  be  written  first  into 
the  buffet,  then  one  green  poloygon.  and  then  a 
matching  adjacent  polygon.  The  two  polygons 
should  meet  on  an  internal  edge  so  as  to  occlude 
the  sky  completely  below  the  top  of  the 
silhouette.  However,  when  the  first  of  the 
mountain  polygons  is  written,  the  fractional 
pixels  on  all  the  edges  will  be  blended  with  the 
background  color,  the  sky.  The  adjacent  green 
polygon  will  then  be  blended  with  edge  pixels 
having  a  sky-colored  component  already  included 
in  those  pixels.  The  net  effect  is  that  a  thin 
line  of  sky  will  appear  along  the  internal  edges 
of  the  mountains. 

One  approach  to  curing  the  problem  is  to  tag 
internal  edges  when  they  ate  first  written  into 
the  buffer  so  that  the  first  internal  edges  will 
completely  overwrite  the  edge  pixels  rather  than 
blend.  However,  there  are  cases  of  vertices  and 
thin  edges  where  there  is  more  than  one  internal 
edge  in  the  pixel.  In  addition,  the  internal 
edges  of  translucent  objects  must  pick  up  the 
background  color,  so  there  are  mote  special 
cases.  Overall,  the  tagging  schemes  are  at  best 
complicated. 


Prior ity-Ordercd  Writing 

To  perform  priority-ordered  writing  with 
ant i-al lasing ,  occlusion  must  be  performed  on  a 
subpixel  basis.  One  way  of  keeping  track  of  the 
subpixels  is  to  keep  a  "bed  of  nails",  a  bit  map 
with  each  bit  corresponding  to  a  subarea  of  the 
pixel.  If  the  bit  is  set  it  means  that  the 
corresponding  nail  has  been  covered;  initially 
all  the  bits  are  set  to  zero.  Only  one  set  of 
color  components  need  be  maintained  for  the  whole 
pixel,  with  additions  made  as  the  nails  are 
filled  in.  This  solves  the  internal  edge  problem 
for  opaque  faces. 

Translucent  faces  now  cause  a  potential 
problem,  however,  because  we  must  decide  what  to 
do  with  the  nails  when  a  translucent  face  is 
written.  If  we  set  the  nails  for  a  translucent 
face,  the  nails  will  not  be  available  for  the 
correct  occlusion  of  underlying  opaque  faces  that 
will  be  written  later.  If  we  don't  set  the  nails 
for  translucent  faces,  then  the  internal  edges  of 
transparent  faces  (which  might  be  almost  100% 
opaque)  will  not  be  anti-aliased  correctly.  In 
any  case,  a  oepatafe  translucency  factor  will 
have  to  be  stored,  adding  to  the  nails  and  color 
components  already  needed  for  each  pixel. 

The  algorithm  to  treat  the  problem  of  top 
down  translucency  is  somewhat  more  tractable  than 
the  problem  of  internal  edges  in  reverse-priority- 
ordered  writing.  The  bed  of  nails  is  a  basic 
mechanism  for  detecting  internal  edges  in  any 
combination  without  having  precomputed  tags. 
Nonetheless,  there  seems  to  be  no  pet  feet 
solution  under  all  combinations  of  multiple 
overlays  of  translucency  and  internal  edges. 

Note  that  the  presence  of  translucent 
objects  also  diminishes  the  overload  resistance 
of  priority-ordered  writing.  If  all  objects  were 
opaque,  only  pixels  intersected  by  visible  edges 
of  surfaces  would  receive  more  than  one 
contribution  requiring  a  write  cycle.  A  total  of 
one  plus  the  intersected  fraction  times  that 
screen  size  would  have  to  be  generated  to  make  a 
frame.  The  fraction  of  edge  pixels  is  small 
(less  than  0.3)  so  the  total  amount  of  processing 
(assuming  skip  over  is  negligible)  is  quite 
predictable.  Translucency  adds  a  potentially 
large  and  variable  amount  of  writing  to  the 
processing,  considering  a  cloud  or  smoke  puff 
covering  the  whole  screen.  Some  restriction  must 
be  placed  upon  the  amount  of  translucency  in  the 
scene  to  protect  the  system  from  such  overloads. 


Distance  Sotting 

Z-buffeied  architectures  have  difficulties 
with  anti-aliasing  and  translucency  implementa¬ 
tions.  To  correctly  occlude  and  suppress 
aliasing  in  the  image,  operations  must  be 
performed  on  a  subpixel  basis.  Since  the 
distance  sorting  is  performed  on  discrete  sample 
points,  the  straightforward  approach  would  be  to 
adopt  sorting  on  a  subpixel  basis.  To  accomplish 
this,  the  distance  and  color  components  of  each 
subpixel  must  be  stored.  The  expense  of  generat¬ 
ing  and  storing  the  Information  for  more  than  one 
or  two  subpixels  seems  prohibitive  with  present 
technology,  so  it  seems  that  Z  buffeted  systems 
must  be  relegated  to  applications  where  image 


quality  Is  not  important,  or  wheie  the  requited 
resolution  is  low.  A  possible  approach  to 
improving  the  image  quality  is  to  store  the  Z 
data  analytically  for  small  blocks  of  the  screen, 
but  this  would  requite  sophisticated  processing 
algorithms. 

Translucency  presents  the  problem  of  storing 
a  number  of  overlaying  faces  that  cannot  be 
resolved  until  the  entire  scene  is  built. 

Building  the  stack  of  data  at  each  pixel  is 
prohibitively  expensive,  so  translucency  cannot 
be  handled  within  the  normal  structure  of  the 
system.  Rather  than  abandon  the  feature 
entirely,  it  is  possible  to  separately  prioritize 
the  translucent  objects  and  add  them  after  the 
rest  of  the  scene  has  been  built.  It  is  easiest 
to  add  the  translucent  objects  in  reverse- 
ptiotity-order ,  with  the  additional  step  of 
checking  distance  for  occlusion  of  the  objects  by 
previously  written  opaque  faces.  The  translucent 
faces  will  have  the  same  internal  edge  problems 
as  ordinary  reverse-priority  architectures. 


CONFLICTS  AMONG  FEATURES 


Textured  Translucent  Surfaces 

Any  operation  which  must  be  performed  on 
each  picture  element  will  require  additional 
pipelined  hardware,  and  it  will  therefore  tend  to 
bo  expensive  to  implement.  This  is  true  for 
operations  such  as  smooth  shading,  smooth 
coloring,  and  haze  fading,  but  texture  is 
especially  expensive  because  the  computations  ate 
mote  complex.  To  save  texture  hardware  it  would 
be  desirable  to  only  put  texture  on  visible 
pixels.  For  example,  a  Z  buffeted  system  could 
save  a  pointer  to  the  texture  mapping  plane 
equation  for  each  sample  point  which  could  be 
used  along  with  the  stored  Z  data  to  compute  the 
texture  modulation  just  prior  to  display.  There 
would  be  some  defect  in  the  anti-aliasing  of  edge 
pixels,  but  no  worse  than  the  regular  Z  buffered 
images.  Similar  schemes  can  be  worked  out  with 
other  architectures. 


The  addition  of  translucency  complicates 
matters.  With  the  possibility  of  overlapping 
textured  translucent  faces,  texture  must  be 
generated  prior  to  the  frame  buffet  input  and  the 
expense  must  be  borne.  To  allow  use  of  texture 
generation  upon  output  in  a  system  with 
translucency,  restrictions  must  be  placed  upon 
the  use  of  texture.  One  possibility  is  to 
prohibit  the  use  of  texture  on  translucent 
surfaces  and  to  store  an  attenuation  factor  for 
the  textute  modulation  on  the  underlying 
surface.  Another  approach  is  to  only  allow 
translucency  for  model  switching  and  to  keep  the 
outlines  of  the  objects  similar  so  that  a  texture 
may  be  applied  using  the  Z  value  from  either 
model;  no  texture  is  allowed  on  models  that  may 
be  switched  completely  out. 

Prior  it izat ion  of  Curved  Surfaces 

There  ate  several  problems  in  integrating 
curved  surfaces  into  the  cited  architectures. 
Ccneral  curved  surfaces  have  concave  features 
that  are  difficult  to  prioritize  by  methods  other 
than  Z  buffeting.  A  restriction  to  convex  pieces 
solves  this  problem,  at  a  significant  loss  in 
generality. 

If  a  large  curved  surface,  such  as  a  terrain 
representation,  must  be  subdivided  for  any 
reason,  there  will  be  a  problem  in  matching  the 
edges  of  the  curved  patches  when  the  patches  must 
change  to  different  levels  of  detail.  This  can 
be  avoided  by  restricting  level  of  detail  changes 
to  small  curved  features  added  on  top  of 
underlying  surfaces.  However,  this  will  limit 
switching  effectiveness  and  also  generally 
require  the  computation  of  the  intersection  of 
the  two  curved  surfaces,  a  much  more  complicated 
requirement  than  bounding  the  surfaces  by  planes. 

SUMMARY  AND  CONCLUSIONS 

This  paper  has  discussed  two  geometric 
processing  architectures  and  four  video 
processing  architectures  in  the  context  of  a  half 
dozen  or  so  image  generator  features.  Each 
architecture  has  strong  and  weak  points  as 
summarized  in  Table  1. 


Architecture 

Strengths 

Weaknesses 

Pipelined  Geometric 
Processor 

Throughput 

Inf iexibi 1 ity . 
complexity 

Parallel  Programmable 
Geometric  Processor 

Flexibility. 

modularity 

Throughput 

Scanl Ine  Video 

Processor 

Requires  little 
memory 

Scanline  overload, 
pi iority-overload 

Reverse-Priority 

Video  Processor 

Easy  translucency 

Internal  edge 
occlusion 

Pt lot ity-Ordered 

Video  Processor 

Over  load 
resistance 

Translucency  implementation, 
large  memory  required 

Distance  Sorting 

Video  Processor 

Easy 

prioritizat ion 

Aliasing, 

translucency  implementation 

Table  1.  Image  generator  architecture  characteristics. 


Foe  any  particular  application,  the 
strengths  and  weaknesses  must  be  weighed.  For 
example.  If  data  base  flexibility  Is  Important 
but  Image  quality  is  not  Important,  the  distance 
sorting  architecture  is  suggested.  On  the  other 
hand,  every  architecture  has  weaknesses.  The 
designer  does  well  to  identify  the  weaknesses  as 
early  as  possible,  and  to  do  the  best  possible  to 
minimize  them  through  innovative  design  or 
appropriate  operational  restrictions.  Users 
should  find  out  what  the  weaknesses  are  and 
assess  those  weaknesses  In  the  light  of  the 
application  requirements. 

For  high  performance  flight  simulation,  the 
author's  opinion  is  that  within  the  next  two  or 
three  years,  reduced  costs  of  processors  a..d 
memories  will  make  a  parallel  programmable 
geometric  processor  with  a  priority  ordered  video 
processor  the  architecture  of  choice.  This 
conclusion  is  based  upon  the  belief  that  overload 
resistance  and  image  quality  ate  extremely 
important  in  this  application.  The  disadvantages 
of  translucency  appear  tractable  with  clever 
design,  and  in  any  case  translucency  is  a  feature 
with  specialized  application  where  some 
limitations  can  be  accepted. 

Hote  generally,  an  important  theme  of  this 
paper  is  that  image  generator  design  must  deal 
with  a  set  of  features  that  must  work  together. 
Features  new  to  the  art  such  as  photographic 
texture  or  curved  surfaces  must  be  combined  with 
all  the  other  features  requited  to  make  a  system 


that  meets  a  given  set  of  requi rements .  Users 
should  therefore  approach  innovative  features 
with  some  skepticism;  the  tradeoffs  must  be 
understood  to  find  out  if  they  meet  the  user's 
requirements. 
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Flight  simulators  provide  a  complete  quantitative  record  of  a  pilot's  flying  performance. 

Evaluating  this  record  is  complicated  by  the  volume  of  data  and  by  its  fine  detail,  dozens  of  flight 
parameters,  sampled  many  times  per  second.  Automated  performance  measurement  systems  (APMS)  reduce  the 
volume  of  data  to  an  amount  which  is  manageable  and  understandable.  The  usual  APMS  is  aircraft  state 
oriented.  The  APMS  keys  on  aircraft  state  (e.g.,  X-Y  position,  bank  angle)  to  define  intervals  over 
which  performance  data  are  integrated.  This  APMS  is  relatively  insensitive  to  pilots'  intentions  and 
so  may  average  performances  which  had  differing  objectives,  based  only  on  their  having  occurred  at  the 
same  point  during  the  task  sequence.  An  alternative  APMS  has  been  developed  which  is  pilot  oriented. 
This  APMS  defines  measurement  intervals  based  on  control  inputs.  Control  inputs  are  identified  by 
discrete  changes  in  flight  path.  These  intervals  are  psychologically  relevant  in  that  they  begin  with 
a  goa 1 -d i rected  control  input  and  end  with  a  countervailing  input.  By  relating  performance  in  the 
pilot  defined  intervals  to  state  defined  intervals,  it  is  possible  to  quantify  performance  on  given 
flight  segments  (e.g.,  a  level  turn),  and  to  specify  factors  which  lead  to  a  given  level  of  performance. 

INTRODUCTION 


As  man-machine  systems  have  become  more 
complex  and  costly,  the  need  for  effective 
measurement  of  operator  performance  has 
increased  dramatically.  Performance  measurement 
systems  (PMS)  are  needed  which  will  permit 
assessment  not  only  of  total  man-machine  system 
performance  but  also  of  performance  factors 
contributing  to  total  performance.  To 
accomplish  this  sort  of  assessment  measures  are 
needed  which  permit  the  decomposition  of 
performance  into  perceptual,  information 
processing  and  physical  control  performance 
components. 

The  need  to  decompose  overall  performance 
into  its  components  is  particularly  apparent 
when  there  is  an  interactive  effect  of  task 
difficulty  factors  on  overall  performance.  For 
example  Rinalducci  (1)  examined  the  performance 
of  pilots  in  maintaining  level  flight  in  an  F - 16 
Simulator.  Rinalducci  used  two  measures  of 
performance,  mean  altitude  above  ground  level 
(AGL)  and  RMS  deviation  from  200  ft  AGL.  Both 
measures  were  sensitive  to  the  effects  of  visual 
cue  and  airspeed  manipulations  as  well  as  to 
difference  between  straight  and  turning  flight. 
In  addition  both  measures  were  sensitive  to 
interactions  between  these  variables.  One 
variable,  visual  cues,  is  clearly  a 
perceptual/informational  factor.  Neither  the 
other  two  variables  nor  the  interactions  are 
amenable  to  intuitive  labeling.  Since  the 
performance  measures  do  not  permit  analysis  of 
component  processes,  it  can  be  shown  that  these 
factors  affect  performance,  but  not  how  they  do 
so. 

Attempts  to  study  component  control 
processes  have  followed  two  lines.  One  approach 
is  to  use  a  discrete  stimulus  such  as  a 
cross-wind  gust  (2)  to  elicit  a  control  input. 
Because  the  input  was  elicited,  it  is  possible 
to  obtain  timing  information,  which  shows  the 
contribution  of  perceptual,  subject  and  control 
task  factors  to  input  latency  and 
effectiveness.  This  approach  provides 
information  not  only  about  how  well  an  operator 
controls  the  vehicle  but  also  about  the 
effectiveness  of  the  operator's  response.  The 
limitation  of  the  approach  is  that  it  can  only 
be  applied  when  inputs  which  are  made  in 


response  to  a  discrete  environmental  change. 

The  ad  lib  control  inputs  which  operators  make 
frequently  in  unperturbed,  steady-state 
operation  are  not  amenable  to  this  approach. 

An  approach  which  has  been  used  to  study  ad 
lib  control  inputs  is  simply  to  measure  the  rate 
of  control  inputs.  An  input  rate  measure  which 
has  been  used  in  the  study  of  driving  is 
steering  reversal  rate  (SRR),  the  rate  at  which 
the  steering  wheel  is  reversed  through  a  small 
finite  arc.  Greenshields  (3)  has  found  SRR  to 
increase  with  traffic  density.  McLean  and 
Hoffman  (4)  have  found  SRR  to  be  affected  by 
lane  width,  speed  and  preview.  Hicks  and 
Wierwille  (5)  found  control  task  difficulty  to 
affect  SRR. 

Although  SRR  is  sensitive  to  the  effect  of 
task  variables  on  ad  lib  control  performance,  it 
has  drawbacks.  MacDonald  and  Hoffman  (in  6) 
found  addition  of  a  secondary  task  to  affect  SRR 
differently  in  simulated  and  actual  driving. 

More  importantly,  SRR  is  often  uncorrelated  with 
overall  steering  performance  (6). 

Control  reversal  rate  has  also  been  employed 
in  flight  control  research.  As  in  driving, 
control  reversal  rate  is  sensitive  to  changes  in 
the  difficulty  of  the  flying  task,  but  the 
sources  of  this  sensitivity  are  obscure. 
Blomberg,  Pepler  and  Speyer  (7)  used  elevator 
position  reversal  rate  (EPRR)  to  measure  control 
performance  in  the  A-300  aircraft.  Blomberg  et 
al  found  introduction  of  an  electronic  flight 
information  system  (EF1S)  to  increase  EPRR. 

Other  measures  of  flying  performance  showed  the 
EFIS  to  improve  pilot  performance.  Introduction 
of  an  autopilot,  which  reduced  the  difficulty  of 
the  control  task  by  controlling  horizontal 
position,  caused  EPRR  to  decrease.  As  in 
driving  control  reversal  rate  is  sensitive  to 
flying  task  difficulty,  but  the  factors 
underlying  this  sensitivity  are  not  clear. 

For  measures  of  ad  lib  control  inputs  to  be 
useful,  indices  of  input  effectiveness,  such  as 
are  available  for  elicited  control  inputs,  are 
needed.  A  PMS  is  presented  here,  which  employs 
measures  of  effectiveness  of  ad  lib  inputs.  Two 
assumptions  underlie  this  PMS:  (1)  the 
conditions  which  prevail  when  the  input  is  made 
serve  to  elicit  the  input  and  (2)  the 
qualitative  effect  of  the  input  reflects  the 
operator's  intention  in  making  it.  That  is,  if 
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an  input  causes  the  vehicle  to  change  direction 
of  travel,  then  the  operator's  intention  was  to 
change  direction.  While  this  assumption  may  not 
apply  to  the  totally  naive  operator,  it  is 
reasonable  for  one  having  even  minimal  skill. 

Measures  based  on  the  above  assumptions  are 
used  to  decompose  control  performance  into  a 
perceptual  task  component  and  a  physical  control 
task  component.  Following  description  of  the 
PMS,  data  are  presented  to  show  effects  of 
perceptual  and  control  task  difficulty  variables 
on  the  performance  measures.  These  data  were 
gathered  in  a  flight  simulator  visual  system 
evaluation,  the  results  of  which  are  presented 
elsewhere  (8).  Tne  intent  here  is  simply  to 
describe  the  functioning  of  the  PMS. 

THE  MEASUREMENT  SYSTEM 

Because  the  intent  of  the  PMS  is  to  provide 
measures  of  performance  which  are  sensitive  to 
the  pilot's  intentions  moment  by  moment,  both 
overall  and  component  performance  measures  need 
be  defined  specifically  with  reference  to  the 
flying  task  considered.  The  PMS  presented  below 
is  used  to  evaluate  performance  in  maintaining 
level  flight  at  a  specified  altitude. 

Four  performance  measures  are  presented  (see 
Table  1).  Two  measures  relate  to  overall 
control  performance:  Target  Altitude  (TA)  is  the 
mean  of  the  local  altitude  minima  and  maxima; 
Altitude  Range  (AR)  is  the  mean  difference 
between  local  maxima  and  minima.  These  measures 
give  the  altitude  the  pilot  is  attempting  to 
maintain  and  the  degree  to  which  the  aircraft 
varies  about  that  altitude.  Target  Altitude  and 
AR  are  analogous  to  conventional  measures  of 
mean  altitude  and  standard  deviation.  Two 
measures,  Smoothness  (S)  and  Critical  Error  Rate 
(CER)  are  used  to  decompose  performance  into  its 
components.  These  measures  are  based  on 
attributes  of  individual  control  inputs. 

Control  inputs  of  interest  are  those  made 
through  the  aircraft  stick.  Unlike  previous 
approaches,  which  have  defined  inputs  in  terms 
of  control  manipulandum  displacement,  the 
present  PMS  defines  inputs  in  terms  of  their 
effect  on  tne  velocity  vector.  This  approach 
has  the  advantage  that  it  employs  a  functional 
criterion  for  defining  an  input,  rather  than  an 
arbitrary  one. 

Table  1 

Performance  measures  for  level  flight 
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OVERALL  PERFORMANCE  MEASURES 
Target  A1 1 itude  ( TA) : 

Mean  of  local  altitude  minima  and  maxima. 

A1 titude  Range  (AR) : 

Mean  difference  between  local  altitude 
maxima  and  minima. 

COMPONENT  PERFORMANCE  MEASURES 
Smoothness  (S): 

Proportion  of  critical  control  inputs. 
Critical  Error  Rate  (CER): 

Ratio  of  lag  distance  to  lag  time  for 
_ critica  l__contrq^  i^n^u ts^ _ 

A  control  input  is  designated  by  a  change  in 
sign  of  the  vertical  acceleration.  If  the 
vertical  acceleration  is  positive  (increasing 
rate  of  climb),  a  control  input  is  said  to  have 


negative  (decreasing  rate  uf  ’  m-:  .  This 
definition  is  analogous  t<  that  jsi-i  tor  TRW. 
This  functional  criterion  makes  the  CMS  highly 
sensitive,  since  control  inputs  are  identifi.  i 
according  to  a  criterion  which  adapts  to  a'l 
task  relevant  factors. 

Once  we  have  determined  that  a  cuntrjl  ogsjt 
has  been  made,  it  is  necessary  to  deter 'in.,  the 
degree  of  effectiveness  of  the  input.  Hue 
control  inputs  are  made  to  affect  y,-!,..  ity,  they 
can  only  fall  into  one  of  two  rat  e  gor  i  ,-s :  ! 

those  after  which  velocity  changes  sign 
(direction  of  travel  changes;  and  those 
after  which  velocity  does  not  chan  je  sign 
(direction  of  travel  remains  the  same  .  with 
regard  to  error  control,  these  two  classes  so 
control  input  effectiveness  nave  psychological 
and  task  relevance  because  in  the  former  case 
the  input  causes  a  decrease  in  error,  while  in 
the  latter  error  continues  to  increase. 

In  the  PMS  critical  inputs  are  those  which 
reverse  the  direction  of  travel  and  so  decrease 
error,  and  non-critical  inputs  are  thosp  which 
do  not  alter  the  direction  of  travel.  Efficient 
control  might  be  expected  to  involve  a 
relatively  large  proportion  of  critical  inputs. 

A  greater  proportion  of  non-critical  inputs 
might  result  in  less  efficient  control  since 
many  inputs  do  not  result  in  error  reduction. 

In  the  PMS  Smoothness  (S)  is  defined  as  the 
proportion  of  control  inputs  which  are  critical 
inputs.  Smoothness  has  a  value  of  1.0  when  all 
inputs  are  critical  inputs  made  for  the  direct 
purpose  of  velocity  control.  If,  on  the  other 
hand,  no  inputs  were  made  for  the  purpose  of 
altering  the  direction  of  travel,  that  is,  none 
were  critical,  then  S  would  have  a  value  of 
0.0.  A  higher  value  of  S  represents  more 
efficient  control. 

As  the  distinction  between  critical  and 
non-critical  inputs  provides  a  finer  grain 
analysis  of  control  behavior  than  simple  input 
rate,  so  a  still  finer  grain  analysis  can  be 
obtained  by  examining  the  effectiveness  of 
critical  inputs.  Since  critical  inputs  are  made 
to  reverse  the  direction  of  travel,  their 
effectiveness  can  be  determined  by  measuring  the 
rate  at  which  error  accumulates  following  the 
input.  An  effective  input  is  one  which  results 
in  a  low  rate  of  error  accumulation.  In  the  PMS 
this  measure  is  given  by  Critial  Error  Rate 
(CER),  the  ratio  of  the  lag  distance  to  the  lag 
time  from  the  critical  input  to  altitude 
mi n i mum/max i mum. 

The  two  measures,  S  and  CER,  permit  the 
decomposition  of  control  performance  into 
behavioral  components.  For  this  decomposition 
to  be  useful,  two  things  are  necessary:  (1)  the 
component  measures  need  be  tied  to 
psychologically  relevant  processes  and  (2)  the 
contribution  of  the  performance  components  to 
overall  performance  must  be  determined.  The 
following  analysis  of  control  performance  in  a 
flight  simulator  addresses  these  issues  through 
examination  of  flying  performance  in  straight 
and  turning  flight  under  varying  conditions  of 
environmental  visual  cue  quality. 


FlYINu  performance  evaluation 


In  trie  flying  performance  evaluation  we 
snail  examine  tne  effect  of  two  task  difficulty 
factors  on  our  measures  of  performance. 

Different  types  of  task  difficulty  factors  will 
De  snown  to  affect  performance  components 
differently.  Tne  interaction  of  tne  components 
in  overall  performance  will  also  be  shown. 
Finally  we  shall  snow  now  overall  performance 
reflects  tne  strategy  adopted  by  tne  pilot  to 
cope  with  decrements  in  component  performance. 

One  of  tne  task  difficulty  factors  addressed 
is  tne  quality  of  out-of -tne-cockpit  visual  cues 
provided  tne  pilot.  De  Maio  and  Brooks  (9)  and 
De  Maio  et  al  (3)  nave  used  tne  slope  (b)  of  an 
altitude  estimation  function  to  evaluate  tne 
altitude  cueing  effectiveness  of  simulator 
visual  environments.  Flying  performance  is 
examined  in  five  environments,  whose  cueing 
effectiveness  ranges  from  b=.2  to  b=.8. 

The  second  task  difficulty  factor  is 
determined  Dy  tne  physics  of  flight.  When  an 
airplane  is  in  wings  level  flight,  the  force  of 
gravity  is  counteroa lanced  directly  by  tne  lift 
vector.  When  tne  aircraft  is  banked,  a  cosine 
component  enters  tne  lift  equation.  This  cosine 
component  increases  tne  difficulty  of  tne 
control  task  in  proportion  to  the  size  of  tne 
Dank  angle  up  to  90°. 

We  will  begin  tne  performance  analysis  by 
looking  at  overall  performance  as  measured  by  TA 
(see  Fig  I).  In  both  straight  and  turning 
flight  TA  increases  substantially  in  those 
environments  providing  poor  altitude  cueing  (D{_ 
•b).  Turning  also  causes  an  increase  in  TA  in” 
all  visual  environments,  but  this  effect  is  not 
as  great  as  that  of  visual  cue  quality. 

Target  Altitude  measures  tne  altitude  tne 
pilot  attempts  to  hold.  In  order  to  see  why 
pilots  raise  TA  with  increased  task  difficulty, 
we  examine  another  overall  performance  measure, 
AR  (see  Fig  2).  Since  AR  measure  bow  precisely 
tne  pilot  controls  altitude,  it  drives  TA  in 
that  tne  TA  must  be,  at  the  least,  nigh  enough 
to  preclude  collision  with  the  ground  on  minimum 
altitude  excursions. 
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Figure  1.  Target  altitude  for  straight 
and  turning  flight 

As  was  true  with  TA,  AR  is  sensitive  to  both 
perceptual  and  motor  control  task  difficulty 


factors.  Tne  pattern  of  the  effects,  however, 
differ  substantially  for  the  two  variables. 
Altitude  Range  is  greater  in  turns  than  in 
straight  flight  at  all  levels  of  altitude 
cueing.  At  low  levels  of  altitude  cueing  this 
difference  is  very  large,  roughly  200  ft. 


Figure  2.  Altitude  range  for  straight 
and  turning  flight 

In  straight  flight  AR  increases  only 
slightly  (@  30  ft)  due  to  cue  quality  variation, 
and  yet  TA  increases  substantially.  At  the  same 
time  a  much  larger  difference  in  AR  due  to 
turning  under  good  cue  conditions  leads  to 
little  change  in  TA.  In  fact  the  function 
relating  TA  to  visual  cue  quality  in  both 
straight  and  turning  flight  is  much  more  like 
the  AR  function  for  turns  than  it  is  like  that 
for  straight  flight.  This  similarity  leads  to 
the  conclusion  that  control  precision 
performance  ( i . e . ,  AR)  in  turns  is  the 
determinant  of  TA  in  both  turning  and  straight 
flight.  Since  turns  must  be  executed,  the  pilot 
chooses  a  straight  flight  TA  which  permits 
maneuvering  comfortably. 

COMPONENT  PERFORMANCE  ANALYSIS 

The  above  analysis  of  AR  permits  us  to 
determine  that  task  difficulty  affects  control 
precision.  The  analysis  of  TA  shows  how  pilots 
might  determine  an  appropriate  altitude  based  on 
their  ability  to  control  altitude.  What  remains 
to  be  shown  is  how  the  perceptual  and  control 
task  factors  act  individually  and  in  concert  to 
affect  control  precision.  This  analysis  is 
accomplished  by  examining  the  performance 
components,  S  and  CER. 

Smoothness  is  a  measure  of  control  input 
efficiency,  the  proportion  of  inputs  that  are 
critical  inputs  (that  is,  effective  in  the  sense 
of  altering  the  aircraft's  direction  of 
travel).  Examination  of  Fig  3  shows  that  S  is 
highly  sensitive  to  altitude  cue  quality  but 
insensitive  to  control  task  difficulty  (bank). 
Changing  the  quality  of  visual  information 
available  to  the  pilot  affects  the  proportion  of 
critical  and  non-critical  inputs  of  the  control 
inputs  made.  When  cue  quality  is  high,  most 
inputs  are  made  to  change  the  direction  of 
travel.  On  the  other  hand,  when  cue  quality  is 
low,  a  relatively  small  proportion  of  inputs  is 
made  for  this  reason. 
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It  is  reasonable  to  suppose  that 
non-critical  inputs,  also,  nave  a  purpose. 

Since  the  proportion  of  these  inputs  increases 
when  altitude  cues  are  poor,  these  inputs  may 
serve  to  give  the  pilot  information  needed  for 
aircraft  control.  When  altitude  cues  are  good, 
only  a  small  number  of  non-critical  inputs  is 
needed  to  provide  flight  control  information, 
and  the  majority  of  inputs  is  made  to  effect 
flight  control.  When  visual  cues  are  poor,  more 
non-critical  inputs  are  needed,  and  so  S 
dec  lines. 


i'i'lIK  i\ i,| in  i  ;  ’iv*  Nl  (fe) 


Figure  3.  MD  smoothness  for  straight 
and  turning  flight 

The  second  component  performance  variable, 
CER,  measures  the  effectiveness  of  individual 
critical  control  inputs;  that  is,  how  quickly 
error  accumulates  following  an  error  reducing 
input.  Since  CER  measures  the  responsiveness  of 
the  man-machine  system,  we  might  expect  it  to  be 
differentially  sensitive  to  control  task 
difficulty  factors.  Examination  of  Figure  4 
shows  this  sensitivity.  Critical  Error  Rate 
increases  from  about  15  ft/sec  in  straight 
flight  to  about  34  ft/sec  in  turning  flight. 

Yet  CER  does  not  vary  systematically  with 
altitude  cue  quality. 

We  have  now  identified  two  components  of 
control  performance:  S,  or  input  efficiency, 
and  CER,  or  input  effectiveness.  These 
performance  components  show  the  differential 
sensitivity  to  task  difficulty  factors  that 
permits  us  to  determine  how  increases  in 
difficulty  affect  the  control  process. 

Increased  perceptual  task  difficulty  leads  to  a 
decrease  in  S  as  more  inputs  are  made  to  provide 
the  pilot  information  and  fewer  for  the  express 
purpose  of  flight  control.  Increased  control 
task  difficulty  leads  to  an  increase  in  CER. 

When  the  control  task  is  more  difficult,  inputs 
are  less  effective. 

Conceptually  the  effects  of  variation  in 
control  efficiency  (S)  or  input  effectiveness 
(CER)  can  readily  be  related  to  overall  control 
performance  ( AR ) .  When  inputs  are  less 
effective  due  to  increased  control  task 
difficulty,  the  aircraft  responds  more  slowly 
and  AR  increases.  When  input  efficiency 
decreases,  due  to  increased  perceptual  task 


difficulty,  directional  changes  occur  less 
frequently  and  again  Altitude  Range  increases. 

In  order  to  demonstrate  a  quantitative 
relation  between  control  efficiency  and 
effectiveness  and  overall  performance,  a  third 
variable  must  be  introduced,  that  is.  Effective 
Input  Duration.  Effective  Input  Duration  (E1D) 
is  the  time  between  inputs  for  non-critical 
inputs  and  the  time  between  input  and  local 
maximum  (minimum)  for  critical  inputs.  The 
difference  in  definition  for  critical  and 
non-critical  E1D  arises  because  the  directional 
change  following  a  critical  input  acts 
psychologically  as  an  input.  Effective  Input 
Duration  is  about  the  same  for  critical  and 
non-critical  inputs,  although  the  inter-input 
interval  is  about  twice  as  long  for  critical 
inputs  as  for  non-critical  inputs. 


Figure  4.  MD  critical  error  rate  for 
straight  and  turning  flight 

Effective  Input  Duration  is  not  a 
particularly  useful  performance  measure  itself 
because,  like  the  input  rate  measures  discussed 
above  (SRR,  EPRR),  it  exhibits  sensitivity  to  a 
variety  of  task  factors  affecting  performance  of 
both  operator  and  aircraft.  Yet  the  difference 
between  EID  and  inter-input  interval  may  be 
useful  in  explaining  some  of  the  conflicting 
input  rate  data  in  the  literature.  Since  input 
rate  is  half  as  great  for  critical  inputs  as  for 
non-critical,  factors  which  affect  S  will  affect 
input  rate  even  if  EID  is  noc  changed. 

Effective  Input  Duration  too  affects  input  rate 
when  S  may  be  unchanged.  Depending  on  the 
magnitude  and  direction  of  these  two  effects, 
input  rate  may  increase  or  decrease  in  response 
to  the  ensemble  of  task  difficulty  factors. 

Altitude  Range  may  be  predicted  from  S,  CER 
and  EID  using  the  function: 

AR  =  2*D*((S*C)+(1-S)*2C)  (1) 

Where : 

AR  =  Altitude  Range,  S  -  Smoothness 
C  =  Critical  Error  Rate  and 
D  -  Effective  Input  Duration. 

Equation  1  says  the  average  excursion  above  or 
below  the  Target  Altitude  is  determined  by  rate 
at  which  error  accumulates  for  a  particular  type 
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of  input  multiplied  by  the  proportion  of  such 
inputs  and  by  the  effective  input  duration.  The 
error  accumulation  rate  for  non-critical  inputs 
is  twice  that  for  critical  inputs  since 
deceleration  to  zero  does  not  occur.  Using  the 
median  values  for  S,  CER,  and  E1D  (see  Table  2), 
Equation  1  predicts  an  AR  of  about  267  ft  in 
turning  flight  with  poor  altitude  cues  (b£ 

.5).  The  obtained  AR  was  260  ft.  In  wings 
level  flight  with  good  altitude  cueing, 
predicted  AR  is  55  ft  while  actual  AR  is  49  ft. 

DISCUSSION 

Two  performance  measures  have  been  developed 
which  permit  the  decomposition  of  flight  control 

Table  2 

Effective  input  duration  (Sec) 

Cueing  Effectiveness  Straight  Turning _ 


Low  TT 
High  lo 


■5) 

■21. 


1.7 

1.3 


2.0 

1.4 


performance  into  component  processes.  These 
component  processes  are  differentially  sensitive 
to  factors  affecting  the  difficulty  of  the 
flying  task.  Smoothness,  the  proportion  of 
critical  inputs,  reflects  the  efficienty  of 
control.  Increasing  the  difficulty  of  the 
perceptual  component  of  the  flight  control  task 
leads  to  a  decrease  in  S.  Critical  Error  Rate 
measures  the  effectiveness  of  critical  control 
inputs.  This  measure  is  sensitive  to  the 
difficulty  of  the  physical  control  task  itself. 

In  order  to  relate  performance  on  these  two 
difficulty  specific  components  to  overall 
control  performance,  a  third  performance 
component,  sensitive  to  general  task  difficulty, 
is  included.  EID  measures  the  amount  of  time 
the  pilot  "holds"  an  input.  At  higher  levels  of 
the  task  difficulty,  EID  increases.  The 
precision  of  control,  AR,  is  a  multiplicative 
function  of  S,  CER  and  EIO. 

The  precision  of  control  is  a  function  of 
component  control  processes  beyond  the 
conscious,  voluntary  control  of  the  pilot.  The 
only  voluntary  control  option  open  to  the  pilot 
is  to  select  a  TA  which  is  a  compromise  based  on 
both  task  requirements  and  limitations  to 
control  precision.  The  pilot  adjusts  this  TA  to 
permit  accomplishment  of  the  flying  task  within 
the  constraints  of  perceptual  and  psychomotor 
1  imitations. 
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ABSTRACT 

The  results  of  a  study  of  the  use  of  computer  generated  imaqery  in  non-traditional  training 
techniques  are  reported.  The^e  techniques  complement  and  extend  the  role  of  a  simulator  from 
that  of  aircraft  replicator  to  that  of  a  traininq  device.  The  study  had  three  primary 
objectives:  1)  exploit  the  flexibility  of  CGI  to  generate  new  concepts  in  aircrew  training 

metnods;  2)  develop  and  demo  trate  examples  of  these  concepts;  and  3)  perform  exploratory 
testing  of  the  examples  to  assess  their  effectiveness  and  pilot  acceptance. 

For  future  study,  the  concept  of  usinq  the  simulator  as  a  specific  visual  task  trainer  is 
discussed. 


INTRODUCTION 

Aircraft  simulators  have  been  designed  and 
used  primarily  as  substitutes  for  actual  air¬ 
craft.  Computer  generated  imagery  (CGI)  pro¬ 
vides  the  flexibility  to  enhance  traininq  in 
ways  that  cannot  be  done  in  an  aircraft.  The 
thrust  of  this  research  was  to  conceive  and 
demonstrate  new  training  approaches  that  take 
advantage  of  the  flexibility  of  CGI.  Two  broad 
categories  of  techniques  were  available  to  us: 

(1)  simulation  of  tasks  untrainable  in  air¬ 
craft  during  peacetime  but  required  during  com¬ 
bat,  and 

(2)  application  of  teaching/learning  met¬ 
hods  unavailable  in  aircraft. 

The  first  category  was  not  emphasized, 
since  many  of  these  special  effects  are  avail¬ 
able  in  present  simulation  visual  systems.  The 
second  category  is  exemplified  by  techniques 
such  as  allowing  the  student  to  view  an  engage¬ 
ment  from  various  viewpoints  (his  own,  the 
threats,  overview,  etc.)  or  making  visible  some¬ 
thing  that  the  pilot  must  visualize  but  cannot 
see  in  the  real  world,  such  as  the  radar  antenna 
pattern  of  an  opposing  aircraft  during  air-to- 
air  combat. 

The  work  has  been  performed  in  a  series  of 
three  one-year  stages.  During  the  first  stage, 
literature  was  searched  and  experts  consulted  in 
the  process  of  generating  concepts  for  aircrew 
training.  During  the  second  period,  real  time 
examples  of  several  of  the  traininq  concepts 
were  implemented  on  a  VITAL  IV  computer  gen¬ 
erated  image  system  at  McDonnell  Douglas 
Electronics  Co.  (MDEC).  During  the  last  stage, 
additional  examples  were  implemented,  improve¬ 
ments  were  made  to  the  previously  created 
examples,  and  exploratory  testinq  was  performed 
both  at  MDEC  and  at  the  Air  National  Guard  faci¬ 
lity  at  Davis  Monthan  Air  Base  in  Tucson, 
Arizona.  In  this  study  report  the  earlier  work 
will  be  briefly  reviewed  and  the  work  performed 
during  the  final  period  will  be  described  in 
detail . 


CONCEPT  GENERATION 

The  initial  stages  of  research  called  for 
the  generation  of  new  concepts  in  aircrew  train¬ 
ing  using  computer  generated  images  combined 
with  a  flight  simulator.  The  emphasis  was  in 
complex  combat  skill  training  as  opposed  to  more 
routine  tasks  such  as  takeoff  and  landing.  This 
was  initiated  by  consulting  with  experts  in  the 
fields  of  human  factors,  training  psychology, 
visual  perception,  combat  flight,  simulation, 
visual  systems  desiqn  and  fliqht  instruction. 
In  addition,  a  limited  literature  search  was 
conducted. 

Table  1.  Key  Complex  Combat  Skills  to 
be  Trained 

Factors  Affecting  Probability  of  Kill  (P|<) 

A.  Energy  Management 
TI  own 

2.  threat  energy  state 

B.  Offensive  Weapons  Systems 
TI  switchotogy 

2.  knowledge  of  best  system  selection 

C.  Assessment  of  Threat  (Current) 

TI  status  assessment 

2.  knowledge  of  what  to  do  about  it. 

Factors  Affecting  Probability  of  Survival  ( P 5 ) 

A.  Energy  Management 
TI  own 

2.  threat  (know  energy  state  of  threat) 

B.  Defensive  Systems  Management 
TI  display  threats 

2.  respond  to  threats 

C.  Assessment  of  Threats 
TI  status/number 

2.  knowledge  of  appropriate  action. 
Maximizing  PK  X  P5 
Low  Level  FI iqht 
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Some  of  the  concepts  resulting  from  this 
effort  were  demonstrated  on  VITAL  IV  computer 
generated  image  systems  at  the  McDonnell  Douqlas 
Electronics  Co.  in  St.  Charles,  Missouri  and  on 
the  A-7D  aircraft  simulator  at  Davis  Monthan  Air 
National  Guard  Base  in  Tucson,  Arizona.  How¬ 
ever,  ideas  generated  could  be  demonstrated  on 
any  computer  generated  imaqe  system.  This  is  an 
essential  point. 

MDEC's  VITAL  IV  system  consists  of  a  gen¬ 
eral  purpose  minicomputer,  special  purpose  hiqh 
speed  computational  hardware,  and  a  calligraphic 
color  display  with  collimatinq  optics.  This 
display  would  normally  be  mounted  outside  the 
window  of  an  aircraft  simulator  cockpit  to 
display  a  representat ion  of  the  "real  world"  to 
the  pilot.  The  simulator  position  and  attitude 
information  is  supplied  to  the  visual  system, 
which  correspondingly  updates  the  visual  scene 
thirty  times  per  second.  Tne  scenes  have  in  the 
past  been  made  specifically  to  simulate  the  real 
world  flight  environment,  including  special  ef¬ 
fects  such  as  variable  weather  conditions, 
surface-to-air  missiles,  air-to-air  missiles, 
anti-aircraft  artillery,  tracer  bullets,  and  so 
forth.  Two  such  systems  were  utilized  for  this 
project.  Basic  studies  in  flight  cue  perception 
were  performed  on  a  laboratory  system  at  MDEC. 
The  remainder  of  the  studies  were  performed  on  a 
three  window  system  on  the  A-7D  operational  air¬ 
craft  simulator  at  Davis  Monthan. 


SAMPLE  IMPLEMENTATION 
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This  section  briefly  describes  the  sample 
concepts  implemented  during  the  second  stage  of 
research. 


Visible  Sensor  Cone 


A  generic  teaching  aid  researched  was  to 
make  visible  something  the  pilot  must  visualize 
but  cannot  see  in  the  real  world.  As  an  example 
of  this  technique,  we  created  a  CGI  scene  of  a 
MIG  threat  aircraft  with  a  visible  "lethal  cone" 
extending  from  its  nose.  The  objective  was  to 
teach  the  student  how  this  normally  invisible 
cone  looks  in  three  dimensions  from  the  various 
positions  attained  during  an  engagement,  and  to 
allow  him  to  develop  techniques  for  avoidinq 
it.  (See  Figure  1) 


Visible  Air  Track  of  Own  and/or  Threat  Aircraft 
In  a  large  number  of  situations  ft  Ts- use¬ 
ful  for  the  pilot  to  be  able  to  view  his  or 
another  aircraft's  flight  path  either  during  or 
immediately  after  a  maneuver.  To  accomplish 
this  we  implemented  a  set  of  contrails  formed  by 
inserting  lightpoints  along  the  flight  path  into 
the  environment  in  real  time  durinq  a  simulator 
flight.  The  advantage  with  this  implementation 
is  that  the  pilot  may  view  the  aircraft  flight 
path  immediately  for  positive  feedback.  (See 
Figure  ?) 


Multiple  Viewpoint  Selection 

One  o7  tne  key  tra i n i nq  needs  frequently 
expressed  by  the  instructor  pilots  as  being  dit- 
fnuli  to  teach  is  referred  to  as  "situation 
awareness.  In  order  to  decrease  this  teaching 
difficults  multiple  viewpoints  in  conjunction 
with  the  visible  air  tracks  previously  discussed 
were  used. 

Bv  viewinq  an  aircraft's  flight  path  from 
the  multiple  viewpoints  after  a  particular  air¬ 
craft  maneuver  is  completed,  provides  the  need¬ 
ed  information  concerning  "situation  awareness" 
to  both  the  instructors  and  students.  The  view¬ 
points  most  frequently  selected  were: 

overview, 
profile  view, 

view  from  qround,  such  as  a  surface  to  air 
missi le  site, 

or  tarqet  aircraft's  view,  (see  Figures  3 
and  4 ) 

Immediate  Bomb  Scoring 

This  technique  displays  Hit/Miss  score, 
aircraft  release  parameters,  and  impact  para¬ 
meters  in  the  visual  display  for  quicker  feed¬ 
back,  which  is  known  to  produce  better  learn¬ 
ing.  The  parameters  displayed  were: 

clock  anqles, 
miss  distance, 
anqle  of  attack, 

"g"  load, 

release  altitude, 

minimum  altitude, 

heading  in  deqrees, 

pitch  in  degrees, 

roll  in  degrees.  (See  Fiqure  5) 

Instructor  Positionable  Cursor 

Cursors  have  long  been  a  valuable  tool  in 
computer-aided  design  applications.  They  would 
be  equally  valuable  as  part  of  the  computer 
generated  scene  in  aircraft  simulation  visual 
systems.  Thus,  we  implemented  an  instructor 
positionable  cursor  controllable  from  the  con¬ 
sole  joystick.  (See  Figure  6) 

Cursor  at  Selectable  Depression  Angles  from  the 
Hori zon 

This  cursor  is  one  which  remains  a  fixed, 
selectable  number  of  degrees  below  or  above  the 
horizon.  This  could  be  set,  for  instance,  to  3 
degrees  depression  and  it  would  represent  a 
desired  qlideslope  anqle  for  landinq.  Any 
object  appearing  centered  in  the  cursor  is  known 
to  be  located  alonq  a  3  deqree  slope  from  the 
aircraft.  If  the  cursor  were  set  at  a  larger 
anqle,  it  could  be  used  to  represent  a  desired 
dive  angle  for  air-to-ground  attack.  Use  of 
this  type  of  cursor  can  help  a  student  learn  the 
correct  sight  picture  for  dive  bombing  or  straf¬ 
ing.  It  can  also  be  a  great  aid  in  learning  to 
visually  judge  and  correct  glideslope  for  land¬ 
inq.  (See  Fiqure  7) 
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Velocity  Vector  Cursor 

This  cursor  Ts  a  visual  indication  to  the 
pilot  of  the  extended  flight  path  of  the  air¬ 
craft,  It  was  found  to  be  useful  for  conveying 
information  about  aircraft  attitude  and  aircraft 
angle  of  attack.  As  with  the  other  cursors  the 
luminance  intensity  was  adjustable,  such  that  as 
students  became  more  proficient  the  cursor's 
intensity  was  progressively  reduced  to  extinc¬ 
tion.  This  assures  that  ultimately  the  stu¬ 
dent's  response  is  evoked  only  by  the  real  world 
cues.  (See  Figure  8) 

Visible  Air 

A  scene  composed  of  16,000  lightpoints  uni¬ 
formly  spaced  to  form  a  cube.  Referred  to  as 
"visible  air"  this  visual  cue  demonstrates  im¬ 
portant  visual  aspects  of  flight.  For  instance, 
by  flying  through  this  scene  a  student  can 
quickly  learn  the  basics  of  how  the  motion  of 
objects  around  the  aircraft  conveys  information 
about  the  aircraft's  position,  motion  and  aim- 
point. 

Energy  Maneuverab i 1 i ty  Diagram 

In  air  combat  it  is  critically  important 
for  a  pilot  to  know  not  only  his  own  aircraft's 
limitations  (performance  envelope)  but  also 
those  of  his  potential  adversaries.  A  useful 
tool  in  this  process  is  the  energy/maneuver¬ 
ability  diagram.  This  is  normally  a  diagram  of 
turn  rate  versus  air  speed.  We  designed  a  new 
type  of  energy/maneuverability  diagram  contain¬ 
ing  altitude  in  addition  to  the  standard  infor¬ 
mation.  The  diagram  consists  of  three  parts: 
Axes  systems,  aircraft  flight  envelopes,  and 
aircraft  energy  state  indicators.  The  axes  con¬ 
sists  of  a  vertical  altitude  axis  and  two  hori¬ 
zontal  velocity  axes,  one  of  ownship,  the  other 
for  the  threat  aircraft.  Each  velocity  axis  is 
positioned,  along  the  altitude  axis  at  the  air¬ 
craft's  current  altitude.  The  altitude  axis  is 
fixed.  The  flight  envelopes  show  the  maximum 
turn  rate  and  the  maximum  sustainable  turn  rate 
at  full  throttle  as  a  function  of  airspeed  and 
altitude  for  each  aircraft.  At  low  speeds  - 
those  below  the  speed  at  which  the  highest  turn 
rate  can  be  achieved  -  the  maximum  turn  rate  is 
limited  by  the  lift  line,  that  is  to  say,  turn¬ 
ing  faster  will  result  in  the  aircraft  having 
too  little  lift  to  stay  airborne.  At  speeds 
above  the  speed  of  maximum  possible  turn  rate, 
the  maximum  turn  rate  is  limited  by  the  struc¬ 
tural  limits  of  the  aircraft  or  the  pilot.  The 
sustainable  turn  rate  divides  the  envelope  into 
two  parts:  an  energy  loss  region  above  it,  and 
an  energy  gain  region  below.  An  aircraft  in  its 
energy  gain  region  and  at  full  throttle  will  in¬ 
crease  speed  or  altitude;  an  aircraft  in  its 
loss  region  will  descend  or  slow  down.  The 
flight  envelope  is  formed  from  nine  velocity- 
turn  rate  points  whose  exact  values  depend  on 
the  aircraft  type  and  the  current  altitude  (see 
Figures  10,  11  and  12). 

Typical  values  were  used  for  our  demonstra¬ 
tions;  they  do  not  represent  any  real  aircraft. 
Each  aircraft's  current  speed  and  turn  rate  is 
indicated  on  its  diagram  by  its  current  state 


marker.  The  threat  aircraft's  state  is  repre¬ 
sented  by  a  dot,  while  ownship's  state  is  repre¬ 
sented  by  an  "X".  A  trail  of  dots  is  attached 
to  ownship's  state  marker  to  show  its  recent 
history.  An  "equivalent  speed"  marker  for  the 
threat  aircraft  is  presented  on  ownship's  dia¬ 
gram  showing  the  threat's  current  turn  rate  ana 
the  speed  it  would  have  at  ownship's  altitude  if 
it  kept  its  total  energy  (kinetic  plus  poten¬ 
tial)  constant.  Finally,  there  is  a  relative 
energy  gain  indicator  which  points  toward  the 
side  of  the  aircraft  that  is  gaining  enerqv  re¬ 
lative  to  the  other  aircraft.  The  tangent  of 
the  deflection  of  this  indicator  from  vertical 
is  proportional  to  the  relative  rate  of  energy 
gain. 


EXPLORATORY  TESTING 

* 

After  implementing  the  above  described  spe¬ 
cial  effects  and  training  aids,  we  began  explor¬ 
atory  testinq  to  determine  whether  the  concepts, 
when  put  into  practice,  indeed  showed  signs  of 
havinq  the  utility  we  expected.  Since  a  broad 
range  of  aids  and  techniques  for  using  those 
concepts  needed  to  be  examined,  we  opted  to  exa¬ 
mine  each  in  a  relatively  cursory  fashion  rather 
than  examine  a  few  in  great  depths.  What  fol¬ 
lows  is  a  description  of  one  of  the  experiments 
performed  and  its  results. 


Non-Real  World  Visual  Training  Cue 

The  intent  of  this  experiment  was  to  ascer¬ 
tain  the  degree  of  influence  the  non-real  world 
visual  training  cues,  velocity  vector  cursor, 
horizon  depression  cursor,  and  visual  airspace 
have  on  simulated  flight  performance. 

Subjects 

The  suject  pool  comprised  20  pilots, 
grouped  into  experienced  and  novice  test  and 
control  groups.  The  average  flight  hours  per 
subject,  in  each  group,  are: 


Control  Hours/Subject 


Experienced 

3 

2041 

Inexperienced 

4 

61 

Total 

7 

910 

Test 

Experi enced 

4 

2800 

Inexperienced 

9 

74 

Total 

13 

913 

Procedure 

The  experimental 

procedure  was  divided 

three  segments: 

pretraininq,  control. 

training.  The  pretraining  segment  was  performed 
by  both  control  and  test  subjects,  control  seg¬ 
ment  by  control  subjects  only,  and  training  seg¬ 
ment  by  test  subjects  only. 


Durinq  the  pretraininq  seqment,  control  and 
test  subjects  were  instructed  in  how  to  use  a 
joystick  driver  for  aircraft  control.  They  were 
instructed  to  fly  the  simulated  aircraft  through 
approaches  and  landings  usinq  3  deqrees  as  a 
glideslope  angle.  The  subjects  were  informed  of 
their  downranqe  distance  and  that  each  approach 
would  have  a  different  altitude  and  crossrange 
distance.  Then  a  practice  period  of  fifteen 
minutes  was  flown  in  which  approaches  were  made 
under  day  and  night  visual  conditions. 
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During  the  control  segment,  control  sub¬ 
jects  were  allowed  an  additional  flight  practice 
period.  This  period  was  equal  in  length  to  the 
training  period  given  test  subjects  during  the 
training  segment.  The  only  difference  was  that 
the  control  subjects  received  no  feedback  or  in¬ 
struction  concerning  their  flight  performances. 

During  the  training  segment,  test  subjects 
were  shown  the  visual  airspace,  horizon  depres¬ 
sion  cursor,  and  velocity  vector  cursor.  They 
were  instructed  concerning  the  operation  and 
usage  of  the  cursors.  The  test  subjects  per¬ 
formed  a  flight  training  period  of  15  minutes 
during  which  the  cursors  were  active  and  the 
subjects  were  given  additional  instruction  in 
the  correct  cursor  operation. 

Crossrange,  downrange,  and  altitude  data 
was  gathered  durinq  the  final  two  approaches, 
one  day  and  one  night.  This  was  done  after  each 
segment  and  once  again  upon  conclusion  of  the 
experiment.  The  final  data  (post  training)  was 
gathered  in  order  to  evaluate  learning  retention 
in  test  subjects  after  the  training  segment. 
The  data  was  later  converted  to  crossrange  ver¬ 
sus  downrange  and  altitude  versus  downrange  gra¬ 
phic  representations  of  the  aircraft's  flight 
path. 

Exploratory  Testing  Results 

After  evaluating  the  control  subjects' 
flight  paths  it  was  observed  that  their  per¬ 
formances  were  little  influenced  by  the  practice 
flight  sessions.  The  final  approaches  from 
pretraining  and  control  sessions  typically 
mimicked  each  other,  demonstrating  an  inability 
to  learn  from  the  additional  practice  flight 
time.  These  results  indicated  that  the  control 
subjects,  both  experienced  and  inexperienced, 
were  unable  or  unwilling  to  either  recognize, 
diagnose,  or  modify  their  flight  deficiencies. 

Evaluation  of  the  test  subjects'  pretrain¬ 
ing  and  training  flight  paths  showed  surprising 
similarities  for  both  experienced  and  inexper¬ 
ienced  qroups.  Both  groups'  pretraining  flight 
paths  deviated  greatly  from  the  correct  ap¬ 
proach.  The  most  common  error  was  in  glideslope 
judgement.  Either  the  pilots  flew  directly  to 
the  runway  or  they  attempted  to  achieve  an  ap¬ 
propriate  glideslope  angle,  but  were  unable  to 
judge  that  angle  correctly.  The  two  groups  also 
performed  similarly  during  the  training  flight 
approaches.  Comparison  of  pretraining  and 
training  flight  paths  revealed  that  the  test 
subjects  were  very  successful  at  using  and 
understanding  the  visual  cursors.  The  most  pro¬ 
nounced  improvements  were  in  qlideslope  angle 
estimation,  error  detection  and  error  correction. 

The  post-training  approaches  were  flown  in 
order  to  determine  whether  the  abilities  ac¬ 
quired  during  training  were  retained.  Results 
indicate  that  only  the  inexperienced  pilots 
whose  flight  time  was  above  that  of  novices  re¬ 
tained  the  skills  gained  through  traininq. 
There  are  several  possible  explanations  of  why 
the  experienced  pilots  did  not  retain  the  skills 


they  gained  during  training.  The  most  reason¬ 
able  of  tnese  is  that  the  visual  training  ses¬ 
sion  of  15  minutes  was  insufficient  to  alter  in¬ 
grained  habits  -  qood  or  bad  -  acquired  through 
extensive  training  and  experience.  We  naven't 
sufficient  data  to  conclude  how  experienced 
pilots  could  best  be  trained  in  order  to  retain 
V:°.  skills  gained  through  training,  but  the  re¬ 
sults  strongly  support  the  need  for  early  visual 
training. 


tudy  were  to  gen¬ 
erate  new  concepts  in  aircrew  training  methods 
that  take  advantage  of  the  flexibility  of  com¬ 
puter  generated  imagery,  to  demonstrate 
examples,  and  to  perform  exploratory  testing  of 
these  examples.  The  purpose  of  the  exploratory 
testing  was  to  provide  a  baseline  of  information 
from  which  detailed  training  experiments  could 
be  designed  for  future  evaluation.  All  of  these 
goals  were  met.  In  general,  we  found  pilot  re¬ 
actions  to  the  demonstrated  examples  to  be  quite 
favorable.  The  key  to  this,  we  believe,  is  the 
fact  that  the  philosophy  under  which  these  con¬ 
cepts  were  generated  was  compatible  with  opera¬ 
tional  instructor  pilots'  and  students'  views. 
The  philosophy  was  that  it  can  be  worthwhile  to 
forego  pictorial  realism  in  favor  of  operational 
realism.  Additionally,  the  approach  to  simula¬ 
tor  utilization  was  as  a  training  tool,  not  as 
an  aircraft  replicator.  It  was  recognized  that, 
when  viewed  as  an  aircraft  replicator,  the  simu¬ 
lator  will  always  be  found  wanting;  however, 
when  viewed  as  a  training  tool,  its  potential 
has  only  just  begun  to  be  explored. 

FUTURE  IMPLEMENTATIONS 

This  section  briefly  describes  continuing 
concept  investigation  of  visual  intelligence. 

Angular  Judgement  Training 

Literature  commonly  used  for  flight  ins¬ 
truction  contain  large  sections  on  how  to  teach 
flight  motor  skills  but  offer  very  little  on  how 
to  interpret  visual  intelligence.  Typical  pilot 
t'-aining  courses  offer  a  smattering  of  visual 
cue  interpretations,  but  do  not  offer  systematic 
visual  judgement  training.  It  is  apparent  that 
the  ability  to  make  precise  judgements  of  angu¬ 
lar  displacement  and  movement  is  a  significant 
factor  in  the  overall  task  of  flying  an  air¬ 
plane,  however,  the  matter  of  teaching  these 
flying  skills  is  seldom  directly  addressed. 

Angular  Judgement  Example 

The  task  o7  judging  a  defined  angle  in 
piloting  an  aircraft  is  forever  present.  The 
pilot  is  expected  to  hold  a  given  pitch  angle, 
turn  to  a  heading,  intercept  a  glide  path,  etc., 
in  his  performance,  however  direct  training  to 
visually  recognize  these  defined  angles  has  been 
haphazard  to  say  the  least.  There's  an  old  say¬ 
ing  that,  "A  qood  landing  requires  a  good  ap¬ 
proach"  and  conversely  “a  poor  approach  means  a 
poor  landing",  and  basically  these  are  correct. 


Exploratory  Testing  Conclusion 
The  objectives  of  this  ; 
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FIGURE  5.  IMMEDIATE  BOMB  SCORING 


FIGURE  13.  DEPRESSION  ANGLE  TO  TOUCHDOWN 


FIGURE  14.  RUNWAY  WIDENING  EXAMPLE 


The  approach  is  defined  as  a  course  with  a  given 
flight  path  lined  up  with  the  centerline  of  the 
runway  and  intersecting  the  runway  near  the  de¬ 
sired  touchdown  point  at  an  acceptable  glide- 
slope  angle.  The  heading  of  the  aircraft  will 
line  up  with  the  centerline  of  the  runway,  un¬ 
less  complicated  by  crosswind  and  present  mini¬ 
mal  problem  in  the  judgement  of  the  heading 
angle  at  this  time. 

The  visual  evaluation  of  the  glideslope  re¬ 
mains  complicated  under  all  conditions.  Al¬ 
though  a  pilot  may  not  be  conciously  aware  of 
the  visual  cues  of  angular  change  he  uses  them 
to  evaluate  progress  of  the  approach. 

Two  of  the  visual  angular  evaluations  re¬ 
quired  for  accurate  qlideanqle  judgements  are  as 
fol lows: 

1.  Depression  angle  of  the  touchdown  point 
from  the  horizon  or  apparent  horizon.  The  im¬ 
portance  of  this  evaluating  cannot  be  over¬ 
stated  because  it  is  an  angle  that  remains  con¬ 
stant  through  the  approach,  is  not  affected  by 
surrounding  elements.  (See  Figure  13) 

2.  Constant  widening  of  the  runway  shape, 
as  a  function  of  decreasing  distance  between  the 
aircraft  and  runway,  is  used  to  assess  the  cor¬ 
rectness  of  the  approach.  To  be  used  effec¬ 
tively,  it  has  to  be  combined  with  vertical 
lengthening  of  the  runway  image,  as  well  as  with 
the  decreasing  vertical  distance  between  the 
horizon  and  the  top  of  the  runway  image.  (See 
Figure  14) 


The  flight  path  and  its  associated  angles, 
angular  changes  and  dimensional  relationships 
provide  valuable  visual  cues  that  are  difficult 
to  demonstrate  in  the  ever-changing  natural  en¬ 
vironment.  Training  aids  such  as  computer  gene¬ 
rated  images  could  be  used  to  present  dynamic 
movement  to  improve  angular  recognition.  The 
computer  generated  image  for  the  illustration 
given  would  require  simple  scene  elements  such 
as  a  horizon  and  a  runway  shape.  The  scene  ele¬ 
ments  needed,  however,  to  promote  recognition  of 
meaningful  movement  in  the  periphery  would  re¬ 
quire  only  single  lightpoints.  The  simple  com¬ 
bination  of  scene  element  and  movement  is  end¬ 
less  when  combined  with  the  task  of  improving 
pilot  skills. 
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ABSTRACT 


The  Air  Force  Human  Resources  Laboratory  is  currently  sponsoring  a  project  to  investigate  the  costs  and 
benefits  of  interactive,  computer-based  simulation  in  support  of  avionics  maintenance  training,  utilizing  a  video  disc 
picture  data  ba^e  to  represent  the  actual  equipment.  The  focus  is  on  simulations  which  support  the  development  of 
genuine  troubleshooting  expertise— the  competence  to  go  beyond  prescribed  procedures.  A  unique  aspect  of  this 
project  is  the  use  of  on-line  task  analyses.  An  on-line  task  analysis  is  defined  as  a  computer-resident  data  base 
representing  the  set  of  goals  and  actions  employed  in  accomplishing  a  task.  Goals  are  divided  into  subgoals  or 
actions,  serving  to  decompose  the  troubleshooting  problem  into  simpler  problems.  Actions  involve  direct 
manipulation  of  equipment.  On-line  task  analyses  may  be  useful  in  the  development  and  delivery  of  quality,  cost- 
effective  maintenance  simulations.  Four  benefits  of  on-line  task  analyses  and  a  methodology  for  the  development  of 
these  analyses  are  presented.  The  associated  potential  training  effectiveness  gains  and  cost  savings  are  currently 
being  tested  empirically. 


INTRODUCTION 


A  major  advantage  of  maintenance  simulators 
over  the  use  of  actual  equipment  for  training  is  that, 
as  a  training  device,  simulators  can  be  designed  to 
support  the  instructional  process,  whereas  actual 
equipment  is  designed  only  to  perform  a  specific 
function.  However,  the  evidence  to  date  shows  no 
training  effectiveness  advantage  of  maintenance 
simulators  over  acutal  equipment  trainers.U  >2)  With 
an  inherent  training  advantage,  why  do  maintenance 
simulators  not  produce  superior  training  outcomes? 

Simulators  incorporating  computer-assisted 
instructional  technology  with  courseware  designed 
specifically  to  train  maintenance  skills  have  the 
potential  to  realize  an  instructional  advantage  for 
maintenance  simulators.  Such  maintenance  training 
systems  are  quite  new  and  the  results  of  empirical 
evaluations  of  these  systems  are  not  yet 
available.^’1*’^  This  paper  describes  how  the 
Interactive  Graphics  Simulator  (IGS)  project  sponsored 
by  the  Air  Force  Human  Resources  Laboratory  seeks 
to  achieve  an  instructional  effectiveness  advantage 
over  traditional  actual  equipment  training. 

The  focus  is  on  simulations  which  support  the 
acquisition  of  genuine  troubleshooting  expertise 
defined  as  the  competence  to  go  beyond  prescribed 
procedures  in  fault  isolation  tasks.  The  approach  is  to 
model  the  task  as  well  as  the  equipment.  Simulator 
'essons  are  designed  so  that  no  equipment  action  may 
u  nerformed  until  the  trainee  has  explicitly 
,  eted  the  cognitive  problem  solving  steps  which 
k  o  making  that  equipment  action. 

The  ability  to  simulate  the  detailed  human 
problem  solving  approach  used  in  troubleshooting  a 
specific  piece  of  complex  equipment  (as  well  as  in 
simulating  the  equipment  itself)  may  result  in 
increased  training  effectiveness.  When 

troubleshooting,  no  purposeful  equipment  action  is 
ever  performed  without  an  objective  in  mind  backed 
up  by  reasoning.  While  the  empirical  evaluation  of  the 
IGS  approach  has  just  begun,  a  method  for  creating 


task -centered  maintenance  simulations  has  been 
developed.  It  is  the  purpose  of  this  paper  to  explain 
this  method. 


INTERACTING  WITH  A 
TASK-CENTERED  SIMULATION 


Before  going  into  the  details  of  how  task- 
centered  maintenance  simulations  can  be  developed,  it 
will  be  helpful  to  the  reader  to  understand  the 
simulation  from  the  perspective  of  a  trainee.  The 
trainee  sits  before  a  keyboard  and  two  video  displays. 
One  display  represents  the  equipment.  User 
inter-ction  with  this  display  is  done  through  use  of  a 
touch  panel.  A  second  display  represents  the  cognitive 
or  problem  solving  component  of  the  task.  User 
interaction  with  this  display  is  done  through  use  of  the 
keyboard. 

The  equipment  display  is  a  standard  color  video 
monitor  on  which  a  picture  data  base  of  the  equipment 
relevant  to  the  task  is  displayed.  The  monitor  is 
equipped  with  a  touch  panel  and,  in  a  fashion  that  has 
become  almost  standard  in  microform  and  video  disc 
simulations  of  equipment,  the  student  accesses 
controls,  readouts,  test  points,  and  components  by 
indicating  with  a  touch  of  a  finger  on  the  video 
monitor  face  that  portion  of  the  picture  to  display  in 
greater  detail.  For  example,  if  a  voltmeter  range  is  to 
be  set  from  100  to  10,  one  begins  by  touching  the 
voltmeter  drawer  on  a  rack  of  equipment  pictured  on 
the  monitor.  The  rack  picture  is  replaced  with  a 
picture  of  the  voltmeter  drawer.  Next,  the  range 
control  is  touched  and  the  voltmeter  picture  is 
replaced  with  a  picture  of  the  range  control,  currently 
positioned  at  100.  At  this  point,  the  "10"  on  the  range 
scale  is  touched  and  the  range  control  picture  with  the 
range  control  set  to  10  is  displayed.  Now,  the  user 
might  touch  an  area  on  the  monitor  screen  labeled 
"done"  to  indicate  that  this  equipment  action  is 
complete. 

The  task  display  is  a  medium  or  high  resolution 
graphics  display  on  which  text,  diagrams,  decision 
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alternatives  and  feedback  messages  are  presented. 
For  example,  suppose  the  trainee  is  developing  a  block 
diagram  of  the  signal  path  involved  in  a 
troubleshooting  problem.  Figure  I  depicts  one1  step  in 
this  process.  Here,  the  trainee  is  focused  on  the 
inputs  and  outputs  for  one  particular  functional  blm  k, 
the  PSC.  The  trainee  has  already  identified  that  the 
input  should  be  50  VIX',  and  has  two  more  signals  to 
identify.  The  text  display  shows  a  graph;' 
representing  the  I’SC  and  its  two  inputs  and  one 
output.  The  signals  already  identified  (i:  this  case, 
the  50  V1YC  input)  are  labeled  and  highlighv*  .  A  text 
prompt  beneath  the  graphic  asks,  "Which  signal  would 
you  like  to  add  to  the  block  diagram  now  ."'  At  the 
bottom  of  the  text  display  are  the  decision 
alternatives  to  be  used  in  answering  this  question.  The 
correct  response  is  either  "reference"  or  "output." 
Feedback  messages  are  associated  with  each  incorrei  t 
response.  In  this  example,  if  the  trainee  had  chosen 
"input,"  the  feedback  message,  "You  have  already 
identified  this  signal,  pick  another!"  would  have  been 
displayed. 


intermediate  step  in  the  development  of  u 
block  diagram.  Here  the  trainee  has  already 
identified  that  the  INPUT  should  be  50  VDC 
and  has  two  more  signals  to  identify. 

Interaction  on  the  task  display  continues  until  an 
equipment  action  is  required,  say  for  example,  "Set  up 
voltmeter."  At  this  time,  control  is  passed  to  the 
equipment  display.  When  the  voltmeter  is  correctly 
set  up,  control  is  again  returned  to  the  task  display,  in 
this  way,  a  simulation  proceeds  from  an  initial  task 
display  in  which  the  problem  scenario  is  set,  through  a 
series  of  task  displays  leading  to  the  first  equipment 
action,  through  the  equipment  action  simulated  on  the 
equipment  display,  and  back  to  the  next  task  display. 
This  process  continues,  alternating  between  the  task 
and  equipment  displays,  until  the  problem  is  solved. 
The  simulation  is  task -centered  in  the  sense  that 
planning  and  problem  solving  activity  controls  access 
to  equipment  manipulation. 
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On-Line  Task  Analysis 

An  on-line  task  analysis  is  d.etned  as 
computer-resident  data  base  representing  tin*  set  o: 
goals  aiid  actions  employed  in  accomplishing  a  task.  It 
is  a  problem  reduction  tree.^  It  represents  a  problem 
solving  strategy  known  as  hierarchical  decomposition 
or  planning  by  abstraction,  wherein  the 
troubleshooting  problem  is  divided  into  simpler  and 
simpler  subproblems. 

One  way  to  arrive  at  this  type  of  task  analysis  is 
to  ask  continually  the  question,  "In  order  to  get  the  job 
done,  what  must  I  do?"  If  three  things  must  be  done; 
A,  B,  and  C,  one  repeats  the  question  with  each  of 
these.  "In  order  to  do  A,  what  must  I  do'1"  The 
process  is  repeated  until  the  answer  to  "What  must  I 
do?"  belongs  to  the  assumed  repertoire  of  the  trainee, 
and  is  in  a  sense  elemental.  For  example,  changing 
the  range  on  a  voltinete,  from  1 00  to  10  would  be 
considered  elemental. 

The  nature  of  the  relationship  between  the  task 
and  the  equipment  is  neatly  represented  by  the  on-line 
task  analysis  itself.  The  on-line  task  analysis  has  the 
form  of  a  tree.  The  root  node  of  the  tree  represents 
the  task.  From  it  emanate  several  brant  lies  to  nodes 
representing  the  major  subcomponents  of  the  task. 
From  each  subcomponent  emanate  branches  to  nodes 
representing  their  decomposition,  and  so  on,  until  the 
task  is  decomposed  into  elemental  equipment  actions. 
Therefore,  all  equipment  actions  are  terminal  nodes  in 
the  tree. 

The  target  task  of  the  KiS  project  is  the 
operation  and  maintenance  of  an  F-111  avionics  tost 
stand. (^>8)  Figure  2  provides  an  abbreviated  listing  of 
the  task  analysis  for  this  job.  The  full  analysis  tree  is 
up  to  16  levels  deep  and  contains  between  1,000  and 
2,000  nodes  at  present. 


Benefits  of  On-Line  Task  Analysis 

On-line  task  analysis  can  be  useful  in  the 
development  and  delivery  of  quality  maintenance 
simulations.  Four  benefits  of  on-line  task  analysis  are 
presented  here.  We  remind  the  reader  that  the 
associated  potential  training  effectiveness  gains  and 
cost  savings  are  currently  being  tested  empirically. 
After  this  discussion  of  how  to  use  on-line  task 
analysis  in  the  development  and  delivery  ol 
simulations,  a  method  tor  developing  the  task  analvsis 
itself  is  presented. 
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Figure  2.  Task  analysis  tree  for  6883  maintenance. 

Only  one  line  of  decisions/actions  is 
represented;  all  others  have  been  pruned,  as 
indicated  by  the  ellipses.  Task  elements 
listed  in  italics  are  terminal  nodes  and 
entail  equipment  manipulation. 

Benefit  I:  The  focus  of  the  simulation  is  shifted 
from  the  equipment  to  the  task.  A  commitment  to  the 
use  of  on-line  task  analysis  makes  equipment 
simulation  subordinate  to  the  task.  This  graphically 
depicted  by  the  fact  that  all  equipment  actions  are 
terminal  nodes  in  the  task  analysis  tree.  Given  this 
approach,  the  role  of  the  simulator  is  clearly  defined 
as  a  training  device,  serving  training  objectives,  and 
not  merely  an  alternate  form  of  the  actual  equipment. 

The  simulation  of  equipment  is  a  vital  aspect  of 
this  approach  to  maintenance  simulation;  eventually, 
there  must  be  some  way  to  practice  equipment 
actions.  The  equipment  may  be  simulated  by  a  video 
disc,  a  2-dimensional  flat  panel  simulator,  or  a  3- 
dnriensional  high  fidelity  mock-up.  The  advantages  of 
each  form  of  equipment  simulation  apply  only  to  the 
equipment  simulation  component  of  a  task -centered 
maintenance  simulation. 

Benefit  2:  Computer-based  simulation  course¬ 
ware  is  developed  by  simply  flagging  a  path 


through  the  task  analysis  tree  for  e.,  h  fault.  Trus 
process  is  supported  b\  an  authoring  "d.tor.  I'm 
editor  displays  a  Parent  node  with  the  names  a: 
immediate  subordinate  nodes  underneath  I  see  I  ig  ;m 
3).  A  subject  matter  expert  (sMLl  mows  down  the 
task  hierarchy  bv  expanding  nodes. 
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Figure  3.  Using  the  authoring  editor  to  move  through 
the  task  tree.  In  this  figure,  the  node, 
"Response"  is  expanded,  corresponding  to 
moving  down  one  level  in  the  task  tree 
depicted  in  Figure  2. 

A  simulation  is  built  as  follow  s.  Beginning  w  ith 
the  top  node,  the  SME  selects  which  subordinate  nodes 
must  be  performed  at  this  level  of  detail.  The  list  of 
subnodes  is  the  same  list  of  decision  alternatives 
presented  to  the  student  during  simulation  run  time. 
Subnodes  may  be  assigned  in  order  (e.g.,  "You  must 
first  do  A,  then  B,  and  then  O."),  or  they  may  be 
combined  in  various  logical  combinations  (e.g..  "You 
must  first  do  either  A  or  C,  then  you  must  do  ,  and 
then  you  must  do  A  again.").  Associated  with  each 
assigned  node  is  the  task  or  equipment  display  that 
will  be  presented  to  the  trainee  when  that  decision 
alternative  is  pending.  Recall  that  a  task  display 
contains  text  and  graphics  summarizing  the  current 
state  of  the  problem  and  a  menu  of  decision 
al ternatives.  Figure  I  depicted  a  typical  task  display. 
The  trainee  responds  bv  typing  in  ’he  text  of  the 
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decision  alternative  chosen.  Feedback  messages  are 
created  by  the  SME,  one  for  each  decision  alternative 
for  each  assigned  subnode.  Figure  4  illustrates  the  use 
of  the  simulation  development  editor. 
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Figure  4.  Simulation  courseware  development  editor. 

This  display  corresponds  to  the  task 
structure  depicted  in  Figure  2.  Suppose 
"Check  Patch  Panel"  was  the  method 
selected  for  checking  the  switching  signals 
of  TPS  Group  II  relays  (refer  to  Figure  2). 
When  the  "Check  Patch  Panel"  node  is 
expanded,  the  above  display  appears  with 
the  task  components  listed  on  the  left  and  a 
blank  screen  on  the  right.  The  SME,  using 
editor  commands  normally  listed  at  the 
bottom  of  the  screen,  assigns  the  task 
components  required  to  perform  the  patch 
panel  check  for  this  problem.  The  result  is 
the  list  of  task  components  shown  on  the 
right-hand  side  of  the  screen.  At  this  point, 
if  the  SME  entered  a  "2,"  this  would  cause 
the  "Set  Up  Measurement  Device"  node  to 
be  expanded  and  the  process  of  simulation 
courseware  development  would  continue. 
Task  displays  are  created  by  entering  a 
command  to  "create  task  display"  and  the 
number  (from  I  to  5  in  this  example)  of  the 
task  action  to  associate  with  the  display. 
Feedback  messages  are  similarly 
constructed.  The  menu  the  trainee  sees  at 
the  bottom  of  a  task  display  is  retrieved 
automatically  from  the  task  analysis  tree 
and  consists  of  ail  items  listed  on  the  left- 
hand  half  of  the  editor  screen. 

After  the  subnodes  of  a  given  node  have  been 
assigned  and  associated  with  graphics,  text,  and 
feedback  messages,  the  SME  expands  the  problem.  If, 
for  example,  in  Figure  4,  the  first  assigned  subnode  of 
"check  patch  panel"  is  "1.  install  cover,"  the  author 
will  ask  the  authoring  system  to  "expand  1."  This  will 
cause  the  subnodes  of  "install  cover"  to  be  listed,  and 
the  SME  will  select  which  of  these  subnodes  must  be 


accomplished  in  what  logical  order  to  complete 
successfully  this  subtask.  Task  displays  and  feedback 
messages  are  created  for  each  of  these  assignmen’,. 
The  process  is  repeated,  over  and  over  again  until 
terminal  nodes  are  reached. 

Terminal  nodes  are  predominantly  equipment 
actions.  The  equipment  actions  are  defined  in 
whatever  fashion  is  suitable  to  the  method  chosen  for 
representing  the  equipment.  In  the  1GS  project,  the 
equipment  is  represented  by  video  disc  images  on  the 
equipment  display.  In  this  case,  an  equipment  action 
is  defined  as  a  sequence  of  video  disc  images  and 
touch  inputs  corresponding  to  the  equipment  action  to 
be  performed.  The  example  at  the  beginning  of  this 
paper,  setting  the  voltmeter  range  to  10,  would 
require  that  a  sequence  of  video  disc  images  and  touch 
areas  be  set  up  corresponding  to  the  following 
sequence:  select  the  voltmeter  from  the  rack  of 
equipment,  select  the  range  control  from  the  pictured 
face  of  the  voltmeter,  touch  the  area  labeled  "19,"  and 
press  "done." 

Simulation  development  time  under  this 
approach  can.be  extremely  rapid.  An  SME  can  flag 
the  solution  path  for  a  given  fault  in  a  matter  of 
hours.  It  may  take  only  20  to  40  additional  hours  to 
complete  the  simulation  by  building  the  task  displays 
and  equipment  sequences  associated  with  each  node 
assigned  to  the  solution  path.  Such  a  simulation  may 
take  the  student  an  hour,  perhaps  2  hours,  to 
complete.  These  figures  are  meant  to  convey  only  a 
qualitative  feel  for  how  this  authoring  approach 
facilitates  the  simulation  development  effort.  Precise 
quantitative  data  on  the  cost  of  simulation 
development  will  be  in  the  IGS  final  report. 

In  summary,  the  availability  of  an  on-line  task 
analysis  provides  a  ready  means  of  developing 
simulations.  The  decision  alternatives  for  each  step 
are  provided  by  the  task  analysis.  The  SME  simply 
assigns  steps  appropriate  to  solving  the  fault  at  hand 
and  associates  task  or  equipment  display  information 
with  each. 

Benefit  3:  This  approach  promotes  consistency 
in  problem  solving  approach  at  the  same  time  it  allows 
for  flexibility  in  simulation  design.  Since  all 
simulations  are  developed  from  the  same  task  analysis 
tree,  they  present  a  consistent  problem  solving 
approach.  That  is,  any  menu  (list  of  decision 
alternatives)  displayed  in  one  simulation  will  be 
exactly  the  same  in  all  other  simulations  which  need 
to  display  that  menu.  The  menus  are  not  entered  by 
the  SME  in  the  task  display.  They  are  provided  by  the 
task  analysis  tree.  Only  the  correct  choices  are 
provided  by  the  SME.  This  consistency  in  approach 
from  simulation  to  simulation  assures  that  the  set  of 
simulations  is  coherent  and  should  help  reinforce 
learning. 

This  approach  to  authoring  also  supports  a  wide 
degree  of  latitude  in  constructing  a  simulation 
problem.  In  particular,  it  supports  the  development  of 
part  tasks  and  the  development  of  alternative 
troubleshooting  approaches.  An  example  will 
illustrate  one  way  in  which  part  tasks  can  be 
developed.  Suppose  decision  alternatives  at  some 
point  in  the  simulation  include  complete  block 
diagram,  visual  inspection,  and  check  signals.  It  may 
be  the  SME's  wish  at  this  time  to  focus  on  the  check 
signals  component  of  the  task,  and  glaze  over 
completing  the  block  diagram  and  visual  inspection. 


In  order  to  accomplish  this,  the  SME  can  assign 
all  three  subnodes,  in  sequence.  But  the  SME  will  not 
fill  out  in  detail  the  paths  for  "compete  block- 
diagram"  and  "visual  inspection."  Instead,  a  summary 
scene  for  each  of  these  two  component  tasks  will  be 
created  summarizing  w'hat  the  trainee  would  have 
accomplished  had  these  subtasks  been  completed. 
Only  for  the  check  signals  subtask  will  the  SME  trace 
out  the  entire  path.  The  scenario  for  trainees  would 
go  as  follows.  "What  would  you  like  to  do  next- 
complete  block  diagram,  visual  inspection,  or  check 
signals?"  Trainees  select,  correctly,  "complete  block 
diagram."  In  response  to  this,  the  trainees  see  a  task 
display  showing  a  completed  block  diagram  and 
stating,  "Here  is  your  completed  block  diagram,  press 
NEXT  to  continue."  Again  the  trainees  see  the 
following  decision  alternatives:  complete  block 
diagram,  visual  inspection,  or  check  signals.  This  time 
they  choose  "visual  inspection"  and  again  receive  a 
summary  of  what  this  task  would  have  yielded  at  its 
completion  and  are  returned  again  to  the  following 
choice:  complete  block  diagram,  visual  inspection,  or 
check  signals.  Now,  when  trainees  pick  "check 
signals,"  they  do  not  get  a  summary,  but  instead,  get  a 
task  display  with  the  decision  alternatives  appropriate 
to  performing  the  next  step  in  the  decomposition  of 
the  check  signals  task.  In  sum,  through  judicious  use 
of  summary  scenes,  a  designer  can  tailor  a  simulation 
as  needed. 

The  authoring  approach  also  supports  the 
development  of  alternative  troubleshooting  strategies. 
For  example,  suppose  any  of  three  functional  areas,  X, 
Y,  or  Z,  might  be  explored  next.  Further  suppose  the 
fault  lies  in  region  X.  The  author  can  assign  these 
areas  as  follows:  "X,  Y,  and  Z  may  be  performed  in 
any  order;  Y  and  Z  are  optional,  X  is  required."  As  a 
second  example,  suppose  either  of  two  methods  for 
checking  a  certain  signal  is  acceptable.  Suppose  that 
one  method  is  the  favorite  of  one  SME  and  that  the 
other  is  the  favorite  of  another.  If  both  methods  are 
to  be  followed  through  in  detail,  one  can  assign  them 
as  follows,  "Do  either  Method  A  or  Method  B."  The 
task  analysis  subtrees  for  both  Method  A  and  Method  B 
follow  beneath  the  node  for  each.  If  development 
resources  do  not  permit  building  paths  for  both 
methods,  and  it  is  still  perceived  to  be  important  to 
give  the  trainee  the  option  of  selecting  either  method, 
a  summary  scene  can  be  '■ssociated  with,  say,  the 
choice  of  Method  B,  stu  ig,  "Yes,  you  could  use 
Method  B.  This  is  a  perfectly  legitimate  approach. 
However,  today  we  would  prefer  you  to  try  Method  A." 

Benefit  4:  Interaction  with  the  student  at  each 
simulation  step  can  be  adapted.  As  trainees  master  a 
task,  it  becomes  appropriate  to  support  the  chaining  of 
commonly  co-occurring  equipment  actions.  For 
example,  consider  the  task  of  setting  up  a  voltmeter 
to  make  a  certain  measurement.  Perhaps  the 
voltmeter  has  10  controls,  and  4  of  these  need  to  be 
set  to  make  this  measurement.  Assume  that  the  task 
of  setting  up  a  voltmeter  is  not  in  the  repertoire  of 
the  trainee  early  in  the  training  regimen  but  that  this 
task  certainly  should  be  later  on.  It  is  appropriate, 
then,  that  the  task  of  setting  up  the  voltmeter  be 
represented  explicitly  in  the  on-line  task  analysis. 
That  is,  each  control  is  treated  as  a  separate 
equipment  action,  and  each  control  to  be  set  must  be 
selected  explictly  on  the  task  display  before  it  can  be 
set  on  the  equipment  display.  This  is  very  helpful  for 
trainees  who  have  not  yet  mastered  the  task  of  setting 
up  the  voltmeter. 


Eventually,  as  a  consequence  of  practice,  this 
task  becomes  familiar  and  it  is  no  longer  appropriate 
to  force  trainees  to  plan  separately  for  and  then  make 
each  control  setting.  It  is  appropriate  to  allow  the 
trainee  to  select  the  goal  "set  up  the  voltmeter"  and 
then  go  directly  to  the  equipment  display  and  perform, 
in  an  integrated  fashion,  each  of  the  control  settings 
needed.  In  other  words,  the  detail  or  graininess  of  the 
simulation  should  adapt  to  the  trainee's  level  of 
competence.  This  can  be  achieved  through  use  of  the 
on-line  task  analysis. 

In  this  example,  each  time  the  trainee  sets  a 
voltmeter  control,  the  performance  on  that  task  is 
recorded.  If  the  task  is  performed  correctly  a  given 
number  of  times,  then  simulation  run-time  control  of 
that  equipment  action  is  passed  to  the  next  higher 
level  in  the  on-line  task  analysis.  So,  if  the  four 
controls  that  need  to  be  set  have  all  been  performed 
correctly  as  separate  tasks,  the  next  time  the  task 
"set  up  voltmeter"  is  encountered,  all  equipment 
displays  under  this  node  can  be  run  as  a  single, 
integrated  equipment  display  without  intervening  task 
displays.  To  summarize,  in  the  beginning,  the  task  of 
setting  up  the  voltmeter  was  four  separate  task 
decisions  each  followed  by  an  equipment  action.  As 
soon  as  mastery  of  these  component  processes  was 
demonstrated,  the  task  of  setting  up  the  voltmeter 
became  one  single  task  decision  followed  by  one  single 
equipment  action.  Figure  5  summarizes  this  process. 
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Figure  5.  Chaining  equipment  manipulations.  As  a 
consequence  of  demonstrated  proficiency  in 
setting  voltmeter  controls  (left-hand 
training  sequence),  the  system 
automatically  adapts  and  subsequently 
permits  the  separate  equipment 
manipulations  to  be  chained  together  as  one 
integrated  equipment  action  (right-hand 
training  sequence). 

To  generalize,  this  approach  is  used  throughout 
the  on-line  task  analysis  tree.  Each  trainee  has  a 
student  model  consisting  of  the  on-line  task  analysis 
annotated  with  a  record  of  his  or  her  performance  at 
each  node.  As  the  trainee  gains  experience  in  a  given 
node,  it  undergoes  a  state  transition  from  one  state  to 
another.  For  task  display  nodes,  the  state  transition 
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series  is  as  follows:  recognition,  recall,  performance, 
summary.  Recognition  means  that  the  menu  is 
displayed;  decision  alternatives  are  explicit.  Recall 
means  that  the  menu  is  not  displayed;  decision 
alternatives  must  be  retrieved  from  memory. 
Performance  means  that  all  subordinate  task  display 
nodes  are  ignored  and  only  the  subordinate  terminal 
nodes  (the  equipment  actions)  are  run.  Finally, 
summary  means  that  no  further  action  need  be 
performed  by  the  trainee;  the  results  of  the  actions 
which  would  have  been  required  are  summarized. 

Applying  this  scheme  to  the  voltmeter  example 
results  in  the  following  scenario.  At  first  the  student 
must  recognize  from  a  list  of  controls  the  correct  ones 
to  set,  select  each  control  in  turn,  and  perform  the 
associated  equipment  action  on  the  equipment  display. 
As  each  control's  node  enters  the  recall  state,  each 
control  must  still  be  selected  verbally,  its  name  must 
be  recalled  from  memory,  and  the  associated 
equipment  action  taken.  As  each  control's  node  enters 
the  performance  state,  simulation  run-time  control  of 
the  equipment  actions  is  taken  over  by  their 
superordinate  node,  the  voltmeter  node,  and  the 
student  no  longer  needs  to  separate  the  individual 
equipment  actions— they  are  performed  as  one. 
integrated  whole.  Finally,  when  the  voltmeter  node  is 
in  the  summary  state,  when  the  student  selects  "set  up 
the  voltmeter"  he  or  she  would  receive  the  message, 
"The  voltmeter  has  been  set  up  properly  to  measure 
the  signal  at  hand." 

The  effect  of  this  student  modeling  is  to  focus 
trainee  attention  on  unm  fered  portions  of  the  task, 
potentially  promoting  training  effectiveness  and 
reducing  the  time  needed  to  complete  a  set  of 
simulations.  This  is  done  on  a  completely 
individualized  basis.  Figure  6  gives  a  concise  means  of 
visualizing  the  effect  of  the  adaptive  quality  of  this 
approach. 


Development  of  the  On-Line  Task  Analysis 

Everything  stated  above  presupposes  the 
existence  of  an  on-line  task  analysis.  The  approach  to 
the  development  of  on-line  task  analyses  used  in  the 
IG5  project  is  (1)  to  build  a  skeleton  of  the  task 
analysis  through  traditional  front-end  analysis, 
employing  the  technique  of  hierarchical  problem 
decomposition,  and  (2)  to  refine  and  fill  out  the  details 
of  the  on-line  task  analysis  as  a  consequence  of  trying 
to  use  it. 

Suppose  we  have  entered  into  the  authoring 
editor  the  skeleton  analysis  of  the  job.  Then  we  try  to 
create  a  simulation  using  what  we  have  on-line  so  far. 
The  top  node  gives  us  our  first  set  of  alternatives. 
Presumably,  these  are  useful  in  assigning  the  first  few 
decisions  that  need  to  be  made.  Each  of  these  is 
expanded  in  the  manner  described  in  the  section  on 
building  simulations.  Eventually  a  node  will  be 
expanded  which  does  not  contain  all  of  the  decision 
alternatives  needed. 

For  example,  suppose  we  expand  a  node  and  get 
the  familiar  decision  alternatives  "complete  block 
diagram"  and  "check  signals."  Suppose  the  simulation 
at  hand  requires  that  at  this  point  a  visual  inspection 
be  performed  after  completing  the  block  diagram  and 
before  checking  signals.  Using  the  editor,  this  new 
subcomponent  is  added  to  the  list  of  subcomponents 


for  this  node.  Now  that  "visual  inspection”  is  available 
as  a  decision  alternative,  it  is  used. 


PRIOR  TO  DEMONSTRATION  OF  COMPETENCE 


AFTER  DEMONSTRATION  OF  COMPETENCE 


Figure  6.  Adaptive  simulation.  Prior  to  demonstra¬ 
tion  of  competence  on  a  task  component, 
the  adaptive  model  requires  the  trainee  to 
verbalize  explicitly  task  planning  and  deci¬ 
sions  before  making  the  associated  equip¬ 
ment  manipulations.  After  competence  has 
been  demonstrated,  the  planning  and  deci¬ 
sion  structure  has  been  internalized  by  the 
trainee,  who  may  now  interact  with  the 
equipment  directly. 

The  three  subnodes  at  this  point  in  the  task  are 
assigned  as  follows:  complete  block  diagram,  visual 
inspection,  and  check  signals.  Of  course,  when  the 
visual  inspection  node  is  expanded,  there  is  nothing 
there.  The  strategy  is,  at  this  time,  to  complete  a 
skeleton  task  analysis  for  this  subtask.  The  skeleton  is 
then  used  to  complete  the  expansion  of  the  visual 
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inspection  node  for  the  simulation  at  hand,  adding 
detail  to  the  on-line  task  analysis  as  needed. 

An  on-line  task  analysis  grows  and  becomes 
refined  as  a  consequence  of  developing  simulations. 
Since  the  menus  that  trainees  see  at  the  bottom  of 
each  task  display  are  read  at  simulation  run-time  from 
the  on-line  task  analysis,  all  changes  to  the  on-line 
task  analysis  affect  all  simulations  previously 
developed.  Each  new  decision  alternative  will  appear 
automatically  on  the  appropriate  task  display. 

This  approach  to  developing  an  on-line  task 
analysis  for  use  in  simulation  has  the  major  advantage 
of  ensuring  that  the  task  analysis  is  always  relevant  to 
the  simulations  to  be  developed.  One  need  not  develop 
a  complete  task  analysis  from  scratch.  The  strategy  is 
to  let  the  demands  of  the  simulations  cause  the  on-line 
task  analysis  to  grow.  To  the  extent  that  the  set  of 
faults  simulated  is  complete  and  representative  of  the 
job,  the  task  analysis  will  be  also. 


CONCLUSIONS 


Evidence  to  date  shows  no  training  effectiveness 
advantage  for  maintenance  simulators.  This  evidence 
does  not  include  empirical  studies  of  a  new  variety  of 
maintenance  simulation,  simulators  actively 
incorporating  computer-assisted  instruction 
technology  with  courseware  designed  specifically  to 
train  maintenance  skills.  The  Interactive  Graphics 
Simulator  project  (IGS)  of  the  United  States  Air  Force 
Human  Resources  Laboratory  is  an  example  of  this 
new  class  of  maintenance  simulators.  The  cost 
benefits  and  training  effectiveness  of  the  IGS 
approach  to  maintenance  simulation  are  currently 
being  evaluated  in  the  training  classroom. 

The  IGS  approach  may  successfully  produce  a 
training  effectiveness  advantage  over  traditional 
instructional  approaches  involving  actual  equipment 
because  it  forces  the  trainee  to  interact  with  the 
equipment  in  the  context  of  his  or  her  job.  That  is, 
with  the  IGS  approach,  the  focus  of  the  simulation  is 
shifted  from  the  equipment  to  the  task.  A  second 
feature  of  the  IGS  approach  that  may  translate  into  a 
training  effectiveness  advantage  is  the  ability  to  adapt 
the  simulation  presentation  to  evidence  of  student 
mastery.  The  structure  of  simulations  is  altered 
dynamically  in  a  way  that  focuses  student  attention  on 
unmastered  tasks  and  away  from  mastered  tasks.  The 
consistency  of  a  problem  solving  approach  may  also 
result  in  instructional  benefits. 

As  well  as  potential  instructional  benefits,  the 
IGS  approach  also  provides  instructional  design 
assistance  to  the  subject-matter-expert.  Simulations 
are  easily  created  by  flagging  a  path  through  an  on¬ 
line  task  analysis,  a  computer-resident  data  base 
representing  the  set  of  goals  and  actions  employed  in 
aci  ornplishing  a  task.  The  on-line  task  analysis  is 
robust  enough  to  support  the  development  of  part-task 
simulations  and  alternative  troubleshooting 
approai  hes. 

A  final  important  contribution  of  the  IGS 
approai  h  to  the  field  of  maintenance  simulation  is  its 
methodology  for  the  development  of  on-line  task 


analyses.  The  basis  of  this  methodology  is  to  extract  a 
global  representation  of  a  task  or  job  as  a  consequence 
or  side  effect  of  developing  simulations  oi  instances  of 
the  job.  That  is,  as  individual  simulations  are  built,  a 
composite  representation  is  accumulated.  This 
methodology  may  also  provide  important  inroads  to 
the  development  of  the  knowledge  base  component  of 
expert  systems. 
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ABSTRACT 

The  costs  of  complex  military  flight  simulators  have  been  steadily  rising,  causing  all 
concerned  to  carefully  evaluate  procurement  and  life-cycle  costs  of  these  devices.  In 
making  these  evaluations,  the  issue  is  often  raised  that  commercial  airline  simulators  of 
comparable  quality  can  be  procured  for  less  money  and  with  shorter  schedules.  This  paper 
provides  a  comparison  of  military  and  commercial  procurement  methods,  concentrating  on  the 
major  differences  between  them.  It  analyzes  the  key  discriminators  between  military  and 
commercial  contract  requirements  which  collectively  cause  simulator  procurement  and  program 
practices  to  be  so  different,  and  costs  to  vary  so  widely,  when  the  resultant  flight  simula¬ 
tors  procured  by  both  methods  are  highly  regarded  for  their  training  capabilities.  Recog¬ 
nizing  that  some  of  the  military  requirements  are  unique  and  necessary,  this  paper  takes  the 
position  that  military  simulator  procurement  can  utilize  some  of  the  methods  employed  in 
commercial  procurements  to  reduce  life-cycle  costs.. 


INTRODUCTION 

Simulation  equipment  procurement  practices 
vary  greatly  between  military  and  commercial 
customers.  As  a  result  of  these  different 
practices,  the  cost  of  procuring  military  train¬ 
ing  equipment  is  significantly  higher  than  the 
cost  of  procuring  commercial  training  equipment. 
The  question  ad<re$sed  by  this  paper  is:  are 
there  training  equipment  requirements  which  can 
be  satisfied  at  lower  cost  by  the  application  of 
some  or  all  of  the  commercial  procurement 
practices? 

Both  commercial  and  military  simulators  today 
are  highly  regarded  for  their  positive  transfer 
of  training,  as  a  result  of  efforts  by  the  FAA 
and  military  and  commercial  users  to  reduce  or 
eliminate  the  limitations  found  in  earlier  de¬ 
vices.  The  desired  increases  in  fidelity  have 
been  achieved  in  part  by  the  increased  use  of 
actual  flight  test  data  in  the  simulator  design. 
The  overall  quality  of  commercial  simulators 
today  is  such  that  the  FAA  now  allows  virtually 
all  training  and  crew  certification  to  be  accom¬ 
plished  in  simulators  meeting  FAA  standards.  The 
extensive  use  of  simulators  has  dramatically  re¬ 
duced  commercial  airline  training  in  actual  air¬ 
craft,  similar  to  the  reductions  found  in  many 
military  training  programs. 

This  paper  focuses  on  the  acquisition  aspects 
of  both  military  and  commercial  simulator  pro¬ 
grams,  and  explains  how  operational  consider¬ 
ations  Influence  procurement  requirements, 
practices,  and  costs.  Simulator  maintenance 
support  concepts  are  discussed  and  analyzed  to 
show  how  they  affect  the  requirements  of  the 
contract.  The  elements  of  the  contract.  In  turn, 
are  related  to  the  complexity  of  the  program, 
which  basically  determines  the  program  schedule. 

There  are  alternate  ways  of  obtaining  train¬ 
ing  other  than  procurement  of  either  military  or 
commercial  simulators.  For  example,  a  complete 
training  system  could  be  procured  comprising 
simulator,  part  task  devices,  and  Instructional 
systems  as  Is  done  for  the  training  of  KC-10 
flight  crews  In  conjunction  with  American  Air¬ 


lines  Training  Corp.  Although  this  and  other 
possibilities  exist,  this  paper  addresses  only 
the  direct  procurement  of  simulators  with  con¬ 
centration  placed  on  the  differences  in  procure¬ 
ment  practices. 

A  typical  military  simulator  program  Is 
compared  with  a  typical  commercial  simulator 
program,  with  attention  provided  to  the  obviously 
different  contractual  requirements  and  program 
practices.  These  differences  are  then  evaluated 
for  potential  application  of  the  commercial  prac¬ 
tices  to  military  procurements,  with  the  final 
section  of  the  paper  offering  recommendations 
for  future  consideration. 

Not  all  military  training  needs  can  be 
satisfied  by  the  application  of  commercial 
practices.  For  example,  security  consider¬ 
ations,  nature  of  aircraft,  mission,  and 
geographical  location  may  dictate  all  of  the 
current  supporting  documentation  and  logistlcally 
driven  simulator  characteristics.  However,  cer¬ 
tain  training  applications  could  utilize  simula¬ 
tors  which  are  procured  using  some  or  all  of  the 
commercial  practices  resulting  In  appropriate 
cost  benefits. 

IDENTIFICATION  OF  KEY  DISCRIMINATORS  BETWEEN 
MILITARY  AND  COMMERCIAL  PROGRAMS 

Both  military  and  commercial  simulators  are 
highly  complex  training  systems  which  can  be 
configured  to  meet  individual  customer  needs. 
Table  1  shows  some  of  the  typical  simulator 
features  which  have  been  included  on  Link  simu¬ 
lators.  As  can  be  seen  from  the  table,  except 
for  features  required  for  tactical  training, 
comnercial  simulators  require  the  same  capabil¬ 
ities  as  those  found  on  military  simulators. 
Moreover,  the  completeness  and  fidelity  of  com¬ 
mercial  simulation  in  the  operational  flight 
areas  often  provides  the  same  level  of  training 
effectiveness  currently  provided  by  military 
simulators.  It  must  be  remembered,  however,  that 
military  training  needs  are  understood  and 
accepted,  and  the  proposed  use  of  commercial 
simulators  or  commercial  procurement  practices 
should  not  be  construed  as  a  redefinition  of 
those  requirements. 


Table  1  T  YP 1CAL  SIMULAJUK  FEATURFS 
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This  paper  compares  a  military  simulator 
program  with  a  commercial  simulator  program  and 
discusses  the  various  aspects  of  the  programs 
where  significant  variation  is  evident.  The  two 
programs  selected  represent  typical  military  and 
commercial  program  requirements.  They  are  the 
U.S.  Air  Force  C-130  simulator  program  and  the 
American  Airlines  767  simulator  program.  The 
C-130  program  included  the  development  of  four 
pilot-production  units  and  two  cockpit  procedure 
trainers,  and  the  production  of  six  follow-on 
units.  The  comparison  with  the  767  program  is 
based  on  the  initial  pilot-production  unit, 
which  simulated  the  C-130E  aircraft.  Figure  1 
depicts  the  767  simulator;  the  C-130E  simulator 
is  shown  in  Figure  2.  The  C-130E  simulator 
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(C)  Trainee  Station 


Figure  1.  767  SIMULATOR  (A,  B,  C) 


included  a  full  replica  of  the  pilot,  copilot, 
flight  engineer  and  navigator  stations  as  well 
as  a  satellite  navigator's  station.  The  C-130E 
was  developed  many  years  prior  to  the  simulator 
award  and  the  design  basis  aircraft  itself  was 
several  years  old  at  contract  award.  The  Ameri¬ 
can  Airlines  767  simulator  was  developed  in 
parallel  with  the  aircraft  development/testing 
and,  as  a  simulator  of  a  transport  aircraft,  it 
offers  many  similarities  to  the  C - 1 30  simulator. 
The  initial  configuration  of  the  767  required 
simulation  of  the  pilot,  copilot,  and  flight 
engineer  and  the  extensive  simulation  of  modern 
on-board  computers  and  computer  driven  avionics 
and  displays.  The  767  was  one  of  the  first 
transport  aircraft  to  use  CRT  displays  for  pri¬ 
mary  instrumentation  and  caution  and  warning. 


Because  of  its  parallel  development  with  the 
aircraft,  the  task  of  keeping  the  simulator  con¬ 
figuration  current  with  the  aircraft  required 
extensive  engineering  change  activity.  The  many 
small  changes  were  grouped  together  as  "block" 
changes  and  in  addition,  two  major  configuration 
changes  were  accomplished.  The  aircraft  (and 
simulator)  were  initially  changed  from  a  three- 
crew  configuration  to  a  design  allowing  operation 
by  either  three  or  two  crew  members.  Subsequent¬ 
ly,  the  configuration  was  changed  for  operation 
by  only  two  crew  members. 


Costs 

One  of  the  most  notable  differences  between 
military  and  commercial  simulators  is  that  of 
acquisition  costs.  The  comparison  of  sell 
prices  of  the  two  devices  is  somewhat  distorted 
by  the  differences  in  the  procurement  practices. 
For  example,  contract  clauses  involving  share 
ratios,  ceilings,  customer-furnished  data  and 
aircraft  parts,  etc.  require  detailed  analysis 
in  order  to  make  meaningful  comparisons.  Suf¬ 
fice  it  to  say  that  when  comparisons  are  made, 
the  costs  associated  with  the  development,  test 
and  acceptance  of  the  comparison  programs  showed 
that  the  cost  of  the  C-130E  simulator,  less 
DRLMS,  was  approximately  1.7  times  the  cost 
associated  with  the  AAL  767  program.  Similarly, 
the  costs  of  spares  and  test  equipment  purchased 
on  the  C-130E  program  were  significantly  higher 
than  those  on  the  767  program. 


Another  valuable  comparison  of  costs  is  pro¬ 
vided  by  an  analysis  of  the  engineering  hour 
content  of  the  devices.  The  C-130E  simulator, 
excluding  the  DRLMS,  required  approximately 
450,000  engineering  hours.  The  AAL  767  required 
approximately  130,000  engineering  hours.  These 
engineering  hours  Include  all  engineering,  pro¬ 
gram  office,  and  ILS  hours  required  for  design/ 
test  of  the  basic  simulator  and  associated  data 
items.  This  large  differential  cannot  be  sup¬ 
ported  by  the  differing  complexities  of  the 
devices  (since  they  are  known  to  be  similar). 

The  following  sections  provide  Insight  as  to  why 
this  significant  difference  exists. 
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Figure  2.  C-130E  SIMULATOR  (A,  B,  C) 
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Program  Requirements 

Military  program  requirements  are  specified 
in  more  detail  and  are  more  encompassing  than 
conmercial  program  requirements.  A  commercial 
simulator  is  usually  selected  as  the  most 
“attractive"  device  for  the  offered  price,  and 
as  a  result,  the  specification  is  typically 
written  by  the  contractor  and  subsequently 
negotiated  with  the  customer  if  additions  or 
changes  are  required.  A  typical  commercial 
specification  is  therefore  far  less  detailed 
than  a  military  specification.  A  commercial 
contract  is  typically  50  to  60  pages  in  length, 
including  payment  schedules,  and  all  pertinent 
clauses.  These  two  documents  represent  the 
total  procurement  package  documenting  the 
agreements. 

In  contrast,  military  procurements  involve 
the  detailed  specification(s)  of  the  specific 
training  device,  referenced  specifications,  a 
contract,  a  Statement  of  Work,  a  contract  data 
requirements  list,  referenced  data  item  descrip¬ 
tions  and  various  other  proposal  and  source 
evaluation  documentation.  Once  requirements  are 
levied  and  agreed  to,  it  becomes  necessary  to 
ensure  that  the  requirements  will  be  met.  Mili¬ 
tary  program  management  approaches  by  both  the 
customer  and  the  contractor  become  very  complex 
compared  to  those  on  commercial  programs, 
largely  due  to  the  number  of  specified  require¬ 
ments  and  their  related  activities. 


The  C-130E  PPU  contract  required  the  delivery 
of  a  simulator  plus  95  data  items.  These  data 
items  ranged  from  relatively  small  documents 
such  as  the  facility  requirements  report  (13G 
pages)  to  the  acceptance  test  procedures  (ATP) 
which  included  some  6,000  pages.  A  typical 
commercial  simulator  program  requires  approxi¬ 
mately  20  data  items,  each  with  much  less  com¬ 
plexity/detail.  The  ATP,  for  example  is 
typically  2,000  to  2,500  pages  in  length. 

The  impact  of  data  items  on  a  military  pro¬ 
gram  is  often  misunderstood.  In  many  cases,  the 
costs  allocated  to  an  Individual  item  do  not 
reflect  the  true  cost  of  producing  the  item, 
since  some  or  all  of  these  costs  are  often 
Included  In  the  program  level -of -effort  loading. 
Figure  3  depicts  the  data  submittal  process  and 
provides  insight  into  the  many  steps  required  on 
each  data  item  submittal.  To  complicate  matters, 
typically  20%  to  35%  of  all  Government  specified 
data  Items  require  initial  submission  within  120 
days  after  contract  award.  The  proper  management 
of  a  contract  during  the  start-up  phase  Is  cri¬ 
tical.  Yet  the  magnitude  of  the  data-item-rela- 
ted  efforts  requires  considerable  attention, 
thus  distracting  attention  from  the  simulator. 

In  contrast,  the  efforts  of  both  the  commercial 
contractor  and  customer  in  the  first  120  days  of 
the  contract  are  almost  exclusively  dedicated  to 
the  development  of  the  training  device. 

The  requirements  listed  in  the  various  pro¬ 
curement  documents  add  to  the  complexity  of  the 
program  and  deliverable  product  without  neces¬ 
sarily  affecting  the  complexity/utility  of  the 
training  device.  For  example,  military  simula¬ 
tors  typically  require  reliability  and  maintain¬ 
ability  plans  to  be  submitted  and  approved.  In 


addition,  exhaustive  reports  are  required  which 
analyze  and  allocate  the  reliability  and  main¬ 
tainability  factors  to  the  piece-part  level  to 
"ensure"  end  product  performance  will  be  satis¬ 
factory.  Subsequently,  the  simulator  must  be 
tested  to  prove  that  the  device  meets  the  stated 
requirements,  with  the  obvious  objective  that 
the  simulator  will  perform  and  be  maintainable 
so  that  the  stated  availability  objectives  can 
be  met.  With  these  objectives  attained, 
presumably,  the  simulator  will  support  the  needed 
training  requirements.  Certainly  the  generation, 
review,  submittal,  revisions  and  correspondence 
associated  with  these  plans,  let  alone  their 
implementation,  require  significant  effort. 

The  commercial  approach  regularly  meets  the 
same  availability  objectives  in  a  much  less  com¬ 
plicated  manner.  The  contractor  is  expected  to 
design  to  good  commercial  standards  and  is  held 
accountable  for  the  design/production  of  simula¬ 
tion  equipment  which  meets  the  availability 
requirements  (usually  98%  to  99%).  The  con¬ 
tractor,  concerned  about  his  reputation  as  well 
as  the  contractual  requirement,  is  motivated  to 
produce  a  quality  product,  which  usually  meets 
or  exceeds  the  requirement.  On  the  rare  occa¬ 
sion  when  the  availability  criterion  is  not 
initially  met,  corrective  action  is  taken  until 
the  problem  is  resolved.  In  the  commercial  case, 
the  reliability  and  maintainability  requirement 
is  implemented  by  simply  specifying  the  require¬ 
ment  in  the  contract  and  allowing  the  contractor 
flexibility  in  meeting  it. 

The  military  approach  to  reliability  and 
maintainability  is  more  costly  and  schedule 
consuming,  in  exchange  for  assurance  that  the 
requirements  will  be  met.  A  question  does  exist 
as  to  whether  or  not  the  added  costs  are  justi¬ 
fied  when  one  considers  that  no  substantive 
value  to  the  training  device  is  added  by  these 
requirements. 

In  military  procurements,  there  are  other  re¬ 
quirements  which  are  similar  in  purpose  to  the 
reliability  and  maintainability  requirements 
discussed  above,  whose  effectiveness  can  be 
reviewed.  Some  of  these  requirements  are  intend¬ 
ed  to  provide  on-going  status  and  assurances  of 
program  performance.  The  added  costs  of  these 
check-functions  have  been  justified  as  being 
essential  to  ensure  product  integrity.  A  dis¬ 
cussion  of  the  necessity  of  these  requirements 
will  be  addressed  in  the  next  section. 

Many  requirements  levied  in  military  programs 
are  indeed  necessary  under  current  practice,  al¬ 
though  they  are  not  required  in  commercial  pro¬ 
grams.  These  requirements  are  often  driven  by 
the  maintenance  support  concepts.  For  example, 
if  organic  support  is  used,  then  the  skill  level 
and  turnover  rate  of  the  maintenance  technicians 
must  be  considered.  This  could  result  in  the 
addition  of  requirements,  such  as  the  need  for 
technician  training  courses,  or  in  changing  the 
level  of  the  requirements.  It  would  increase 
the  detail  of  software  documentation,  built-in 
test  equipment,  and  maintenance  publications. 

In  addition,  use  of  the  military  technicians 
also  requires  use  of  the  applicable  logistic 
system.  This,  in  turn,  calls  for  data  and  prac¬ 
tices  which  are  compatible  with  the  user's  logis¬ 
tic  organization  (e.g.,  the  level  and  complexity 


50 


i.^tAU 

■HHM»PuN!.t  M  y 
y  ;  i 


Figure  3.  DATA  SUBMITTAL  PROCESS 


of  the  provisioning  documentation  and  support 
equipment).  These  attendant  requirements  influ¬ 
ence  the  cost  of  the  simulator  program  both 
directly  and  indirectly. 

To  illustrate  this  point,  consider  the  re¬ 
quirement  for  the  use  of  "approved  parts"  which, 
where  feasible,  means  the  use  of  MIL-spec  parts. 
It  is  necessary  to  limit  the  number  of  unique 
part  numbers  in  the  Government  inventory,  and 
MIL-spec  parts  form  the  backbone  of  this  inven¬ 
tory.  The  use  of  MIL-spec  parts  in  the  simula¬ 
tor,  however,  greatly  impacts  its  cost  and 
schedule. 

The  first  obvious  requirement  is  the  effort 
associated  with  early  identification  of  the  re¬ 
quired  parts,  the  contractor's  screening  of  the 
requirements  (to  search  for  the  part  numbers 
consistent  with  previous  submittals/approvals), 
processing  of  requests/rejections,  and  creation 
and  maintenance  of  the  approved  parts  selection 
list.  Several  departments  need  to  coordinate 
these  activities,  and,  accordingly,  program  and 
functional  management  of  these  tasks  is  required 
In  addition  to  these  efforts,  the  cost  to  pro¬ 
cure  the  selected  MIL-spec  parts  will  be  more 
expensive  than  the  equivalent  commercial  part. 

As  will  be  discussed  later,  the  schedule  is  also 
impacted  by  the  use  of  these  parts  and  their 
associated  efforts. 

The  true  cost  impact  of  the  use  of  MIL-spec 
parts  is  very  difficult,  if  not  impossible,  to 
analyze.  Certainly,  the  component  cost  differ¬ 
ential  between  the  MIL-spec  parts  and  the  equiv¬ 
alent  commercial  parts  can  be  argued  to  be 


insignificant  when  considering  their  commonality 
with  existing  inventory.  However,  the  cost  of 
these  parts  is  overshadowed  by  the  costs  of 
performing  the  other  aspects  of  the  parts  con¬ 
trol  program.  These  latter  costs  cannot  be 
easily  estimated  because  the  program  complexity 
is  increased,  which  results  in  increased  sched¬ 
ule,  as  well  as  added  management  and  expediting 
tasks.  Commercial  programs  while  not  requiring 
a  formal  parts  control  program  as  part  of  the 
contract,  rely  on  good  business  practice  to 
achieve  the  same  result.  The  industry  has  con¬ 
sistently  demonstrated  that  devices  sold  as  long 
as  20  years  ago  are  supportable  in  a  cost  effec¬ 
tive  manner. 


Aircraft  Parts  and  Data 

Another  key  discriminator  between  military 
and  commercial  simulator  programs  is  the  method 
of  procuring  aircraft  data  and  parts.  The  typi¬ 
cal  military  program  requires  the  contractor  to 
be  fully  responsible  for  the  procurement  of  parts 
and  data.  These  items  are  normally  on  the  cri¬ 
tical  path  and  therefore  represent  a  major  risk 
to  the  contractor.  If  the  simulator  is  being 
developed  for  a  prototype  aircraft,  these  parts 
are  usually  long-lead  items  because  the  aircraft 
production  line  is  normally  the  aircraft  manufac¬ 
turer's  first  priority  --  i.e.,  the  production 
of  parts  for  the  simulator  has  lower  priority 
and  is  not  included  in  the  production  plan. 
Similarly,  the  generation  of  data  required  to 
support  the  simulator  design  has  lower  priority 
than  aircraft  design,  redesign,  certification 
testing,  and  other  tasks  which  require  the  same 
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people.  In  some  instances  when  the  contractor 
has  full  parts  and  data  responsibility,  the 
Government  is  unwilling  to  intercede  and  assist 
in  obtaining  parts  and  data.  While  this  approach 
appears  to  relieve  the  Government  of  the  risks 
associated  with  late  parts  and  data  delivery,  it 
does  impact  the  program  and  thus,  in  many  cases, 
the  simulator  schedule  and  cost. 

In  contrast,  commercial  airlines  typically 
take  more  interest  in  assuring  that  parts  and 
data  are  available  for  the  simulator  manufac¬ 
turer.  In  many  instances,  the  customer  provides 
the  parts  and  data  as  customer-furnished  equip¬ 
ment.  In  doing  so,  the  customer  can  control,  or 
at  least  more  positively  influence,  the  avail¬ 
ability  of  these  items.  In  some  cases,  the 
airline  management  prefers  to  avoid  any  risks 
associated  with  the  parts  and  data  availability, 
resulting  in  another  approach:  although  the 
responsibility  resides  with  the  simulator  manu¬ 
facturer,  the  customer  takes  the  initiative  to 
influence  the  delivery  dates  and  priority  for 
parts  and  data.  In  some  cases,  this  includes 
pre-ordering  or  reserving  sets  of  parts  and  data 
in  anticipation  of  a  simulator  contract  award, 
which  ensures  timely  availability  of  these  for 
the  simulator  manufacturer.  In  other  instances, 
the  customer  exerts  influence  on  the  aircraft 
manufacturer  through  coordination  efforts.  The 
key  in  either  of  these  approaches  is  that  the 
customer  (whether  military  or  commercial)  has  a 
much  greater  influence  with  the  aircraft 
manufacturer  than  does  the  simulator 
manufacturer. 


Methods  of  Concurrent  Change 


The  design  of  simulators  to  reflect  the  con¬ 
current  change  activity  of  the  parallel  aircraft 
development  is  an  Important  facet  of  a  success¬ 
ful  simulator  program.  The  commercial  simulator 
programs  are  very  effective,  resulting  in  conmer- 
cial  simulators  being  delivered  which  match  the 
configuration  of  the  design-basis  aircraft.  The 
system  employed  permits  an  early  review  of  air¬ 
craft  changes  and,  where  applicable,  incorpora¬ 
tion  of  the  changes  (in  blocks)  in  parallel  with 
the  ongoing  program  activities.  This  is  made 
possible  by  the  advance  authorizations  (based  on 
contractor  cost  estimates)  provided  by  the  air¬ 
lines  to  proceed  with  changes  which  are  subse¬ 
quently  negotiated.  Even  major  aircraft  changes 
can  be  incorporated  in  this  fashion.  As  stated 
earlier,  American  Airlines,  for  example,  con¬ 
verted  their  aircraft  from  a  three-crew  configu¬ 
ration  to  a  two-crew/  three-crew  alternate  con¬ 
figuration  and  subsequently  to  a  two-crew 
configuration.  The  second  simulator  conversion 
was  accomplished  after  testing  had  already  begun, 
but  by  proper  planning,  parts  expediting,  and 
customer  assistance,  the  simulator  started  cus¬ 
tomer  acceptance  testing  reflecting  the  latest 
configuration.  The  net  impact  of  these  major 
modifications  on  the  program  schedule  was  only 
six  months!  These  changes  required  new  data  and 
many  new  aircraft  parts,  including  aircraft 
structures  and  panels,  and  yet  the  simulator  was 
available  to  support  the  critical  training  needs. 


The  military  procurement  system  cannot  oper¬ 
ate  in  this  manner.  A  principal  reason  is  that 
changes  of  any  significance  cannot  be  started 
prior  to  approval  of  the  Engineering  Change 


Proposals  (ECP's).  Since  ECP's  are  ratner  time 
consuming  to  produce  (1  to  3  months),  and  then 
require  time  for  Government  review,  delays 
before  incorporation  are  generally  much  longer 
than  in  the  commercial  application.  Consequent¬ 
ly,  in  many  cases,  the  only  practical  way  a 
contractor  can  accommodate  a  major  change  is  by 
incorporating  ECP's  at  the  end  of  a  program 
because  the  in-process  change  activity  associ¬ 
ated  with  military  procurement  is  much  more 
complex  than  that  of  the  commercial  simulator. 


Support  Concepts 


The  simulator  support  concept  may  be  the  sin¬ 
gle  most  important  element  in  the  procurement  of 
the  simulator.  Therefore  it  is  important  to 
review  and  contrast  the  various  concepts  on 
military  and  commercial  programs. 


The  military  support  concepts  vary  widely 
among  the  various  services  and  in  many  instances, 
within  a  service.  The  C-130  program,  for  exam¬ 
ple,  uses  organic  maintenance,  with  a  total  of 
64  (41  Air  Force  and  23  Civil  Service)  personnel 
required  at  the  Little  Rock  AFB  site  to  support 
four  simulators  and  two  Cockpit  Procedures  Train¬ 
ers  (CPT's).  A  contractor  support  alternate 
which  was  proposed  to  the  Government  would  have 
utilized  29  personnel  to  provide  the  necessary 
maintenance  (20  hours  per  day,  7  days  a  week) 
and  engineering  support. 


One  of  the  most  successful  contractor  simula¬ 
tor  maintenance  programs  is  the  Army  Synthetic 
Flight  Training  System  (SFTS).  That  program  has 
evolved  over  the  last  eight  years,  and  provides 
for: 


1)  Total  contractor  maintenance  support. 


2)  Total  contractor  spares  management  and 
control . 


3)  Training  of  contractor  maintenance  per¬ 
sonnel  to  satisfy  expanding  require¬ 
ments. 


4)  Clear  lines  of  contractor  management 
responsibility  and  authority. 

5)  Reasonable  requirements  for  maintenance 
and  logistic  reporting. 

6)  Army  "owned"  documentation,  spares, 
etc.,  which  permits  recompetition  if 
required. 

The  cost  effectiveness  of  this  support  pro¬ 
gram  is  now  a  matter  of  record.  The  availabil¬ 
ity  achieved  has  been  98%  compared  to  a  require¬ 
ment  of  90%. 


In  the  commercial  sector,  airlines  typically 
maintain  their  simulators  with  a  much  smaller 
team  of  experienced  personnel.  American  Air¬ 
lines  utilizes  its  own  maintenance  personnel 
supplemented  by  one  Link  field  service  person 
for  a  six  month  to  one  year  period  to  augment 
the  staff  on  new  simulators  being  installed. 
American  Airlines  utilizes  43  maintenance  per¬ 
sonnel  dedicated  to  the  support  of  13  simulators 
and  four  CPT's  to  support  training  (20  hours  per 
day,  7  days  per  week). 
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NASA-Ames  recently  procured  a  727  flight 
simulator  and  other  miscellaneous  equipment  to 
conduct  research  on  new  flight  management  tech¬ 
niques  compared  to  conventional  aircraft.  NASA's 
concept  called  for  the  purchase  of  commercial 
equipment  and  commercial  documentation  to  sup¬ 
port  not  only  the  maintenance,  but  significant 
change  activity  by  contractor  personnel.  This 
approach  permitted  the  procurement  of  the  hard¬ 
ware  and  software  at  a  fraction  of  what  would 
have  otherwise  been  required. 


Program  Management  Approaches 

The  program  management  approaches  utilized 
on  military  simulator  programs  are  far  more 
complex  than  those  employed  on  commercial  pro¬ 
grams.  Upon  the  C-130E  contract  award,  a  large 
contractor  program  management  team  (13  members) 
became  essential.  The  many  requirements  not 
only  had  to  be  managed  internally,  but  also  re¬ 
viewed  with  the  customer  and  addressed  in  the 
meeting  minutes,  data  items,  and  correspondence. 
The  C-130E  program  had  a  long  series  of  Engineer¬ 
ing  Design  Reviews  (EDR's)  and  Program  Management 
Reviews  (PMR's)  with  large  numbers  of  Government 
personnel  in  attendance. 


Although  many  of  these  meetings  were  con¬ 
ducted  in  two  or  three  days,  some  lasted  one 
week  or  longer.  The  Preliminary  Design  Review 
required  nearly  two  weeks  and  the  first  of  the 
four  increments  of  the  Critical  Design  Review 
lasted  three  weeks.  These  meetings  generated 
many  action  items  (191  requests  for  action  were 
generated  in  the  C-130E  PDR)  which  again  resulted 
in  more  program  management  attention.  Many  of 
the  action  items  subsequently  resulted  in  corre¬ 
spondence.  It  is  estimated  that  during  the 
C-130E  program,  approximately  1,150  letters  were 
written  by  the  Government,  and  a  similar  volume 
of  correspondence  was  generated  in  response,  by 
Link.  Many  of  these  letters  included  long  at¬ 
tachments  answering  previous  inquiries  or  com¬ 
mentary.  The  efforts  associated  with  this  high 
degree  of  customer  involvement  are  inevitably 
reflected  in  the  cost  of  the  simulator. 


Commercial  simulator  programs  also  rely  on  a 
contractor  program  management  team.  However, 
the  team  is  much  smaller,  usually  consisting  of 
a  program  manager,  a  program  engineer,  plus 
clerical  and  administrative  support.  A  small 
team  can  accomplish  the  program  management 
function  because  the  commercial  program  is  less 
complex,  has  fewer  requirements  supporting  the 
simulators,  and  has  minimal  customer  involvement 
in  the  design  and  management  aspects  of  the 
program.  For  instance,  PDR's,  CDR's,  and  EDR's 
are  typically  not  held  on  commercial  programs. 
Approximately  eight  customer  meetings  with  four 
or  fewer  attendees  are  held.  Far  less  customer 
correspondence  is  required.  Very  few  actions 
usually  remain  at  the  conclusion  of  a  meeting 
since  many  decisions  are  made  during  the  meeting. 
The  commercial  simulator  programs  have  been 
employing  this  program  management  technique 
successfully  for  mere  than  two  decades  indica¬ 
ting  that  formal  PDR's,  CDR's,  and  EDR's  are  not 
essential  management  tools. 


Acceptance  Testing 

Another  significant  discriminator  in  program 
management  approaches  centers  upon  the  acceptance 
process.  The  military  approach  is  characterized 
by  large  Acceptance  Test  Procedures  (ATP)  and  a 
significant  period  of  the  schedule  dedicated  to 
acceptance.  The  acceptance  is  also  supported  by 
a  large  cadre  of  test  team  members. 

The  C-130E  schedule  allocated  four  montns 
for  the  in-plant  customer  acceptance  testing 
(termed  qualification  testing),  with  an  addi¬ 
tional  one  and  one-half  months  required  for  a 
configuration  audit,  reliability  testing,  and 
maintainability  testing.  The  total  in-plant 
customer  acceptance  test  period  (including  the 
audit  and  RS.M  testing)  actually  required  10 
months.  Approximately  20  Government  personnel 
were  involved  with  the  C-130E  acceptance  testing 
at  any  one  time.  The  ATP  was  approximately  6,000 
pages  long.  The  ATP  length  was  required  because 
each  specification  requirement  needed  to  be  spe¬ 
cifically  addressed,  and  each  procedure  was 
written  so  it  could  be  understood  by  entry-level 
technicians  unfamiliar  with  the  simulator.  With 
a  long  test  schedule,  it  was  difficult  to  main¬ 
tain  acceptance  crew  consistency.  As  a  result 
of  personnel  changes,  many  subjective  areas  were 
retested,  causing  further  schedule  extensions. 

A  commercial  simulator  acceptance  process 
minimizes  the  amount  of  subjective  testing  by 
using  a  dedicated  crew/acceptance  team  (usually 
four  or  fewer)  and  automated  test  guides  which 
are  based  on  actual  aircraft  performance.  This 
approach  makes  the  process  more  efficient  and 
objective,  while  maintaining  comprehensiveness. 
Also,  commercial  ATP's  are  typically  much 
shorter.  The  AAL  767  Test  Guide  was  approxi¬ 
mately  2,100  pages.  In  addition,  the  FAA 
requires  a  Test  Guide  to  verify  that  the  re¬ 
quirements  of  the  Advisory  Circular  are  met. 

The  total  767  Interim  Phase  II  FAA  Test  Guide 
was  322  pages  in  length.  The  emphasis  is  always 
on  proper  simulator  operation,  rather  than  exact¬ 
ness  of  the  ATP  format.  Additional  efficiencies 
have  been  achieved  by  accepting  the  contractor's 
running  of  the  ATP,  coupled  with  spot  checking 
by  the  customer.  In  the  AAL  767  program,  AAL 
completed  approximately  40%  of  the  test  guide 
over  a  four-week  period.  The  balance  of  the 
acceptance  period  concentrated  on  fine  tuning 
the  simulator  for  crew  subjectivity  and  on 
obtaining  Interim  Phase  II  approval.  This 
customer  cooperation  and  willingness  to  con¬ 
centrate  on  obtaining  results  in  the  most  effi¬ 
cient  manner  is  a  prime  example  of  how  both 
organizations  benefited  without  sacrificing  the 
objective.  In  this  case,  the  objective  was  to 
get  a  qualified  simulator  in  training  on  sched¬ 
ule.  This  resulted  in  the  timely  training  of  42 
crews  (during  a  six  month  in-plant  training 
period)  and  an  approximate  savings  by  AAL  of  $2 
million. 

The  i ncorpor at i on  of  comprehensive  warranty 
and  update  provisions  in  the  contract  facilitate 
the  acceptance  testing  of  commercial  simulators. 
The  willingness  of  a  commercial  customer  to  make 
more  rapid  decisions  on  the  acceptability  of  a 
simulator  is  based  on  the  security  that  missed 
defects  will  be  corrected.  First,  the  commer¬ 
cial  contract  includes  an  expanded  warranty 
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program  under  which  defects  will  be  corrected 
for  a  specified  period,  typically  two  years. 
Second,  commercial  contracts  in  many  instances 
often  contain  update  requirements,  under  which  a 
specified  number  of  man-months  of  engineering 
support  are  available  to  correct  any  subsequently 
discovered  problems.  Thus,  testing  and  retesting 
the  simulator  in  an  attempt  to  find  every  possi¬ 
ble  defect  is  not  considered  necessary. 

Schedule 


The  program  management  approaches  previously 
discussed  also  have  a  direct  bearing  on  the 
length  of  a  program  schedule.  The  conduct  of 
the  program  directly  influences  the  activities 
associated  with  the  design  and  production  of  the 
simulator.  The  comparison  of  the  ATP  length  pre¬ 
viously  cited  is  directly  translated  into  program 
schedule  requirements.  Further,  the  degree  of 
customer  involvement  in  the  design  review  and 
approval  process  also  has  the  potential  to 
severely  retard  the  schedule. 


Another  significant  discriminator  between 
;  military  and  commercial  simulator  procurements 

]  is  the  schedule.  Typically,  in  both  cases,  sim¬ 

ulator  schedules  are  critical.  Further,  from  an 
investment  viewpoint,  a  shorter  schedule  means 
lower  acquisition  costs,  and  earlier  training 
cost  savings.  The  contractor  is  as  anxious  as 
the  customer  to  reduce  schedules,  since  his 
costs  would  be  reduced,  making  him  more  com- 
■  petitive.  However,  military  schedules  are 

f  typically  much  longer  than  commercial  sche- 

.  dules.  Table  2  compares  the  original  767 

simulator  schedule  with  the  original  C-130E 
•  schedule.  The  program  schedule  accomplishments 

shown  reflect  the  various  changes  during  the 
course  of  the  programs.  The  significant  com¬ 
parison  is  that  despite  the  two  major  aircraft 
|  configuration  changes  and  other  concurrent 

change  activity,  the  767  simulator  required  only 
an  additional  7-1/2  months  to  the  completion  of 
in-plant  acceptance  beyond  the  original  sche¬ 
dule.  The  salient  element  in  this  comparison  is 
that  the  C-130E  required  12  months  longer  than 
the  767  to  complete  in-plant  customer  acceptance. 


Table  2  SCHEDULE  COMPARISONS 
(Months  After  Award) 


ORIGINAL 

C-UOf 

f  INA< 

L- 1  JOE 

original 

76/ 

FINAL 

76/ 

TY5MCAL 
NEM  767* 

Start  of  Hardware  Software 
Integration 

l* 

/I 

U-l// 

14-1/? 

Start  of  lr-Rlant  Customer 
Acceptance 

23 

33 

„>? 

;-9- 1/2 

19 

Complet > on  cf  ln-P)jnl 
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•This  column  shows  the  anticipated  schedule  for  a  new  76/  simulator  which  would  be 
designed  to  reflect  a  new  customer's  conf igurat ion,  training  features,  etc. 


Since  schedules  are  critical  to  both  customer 
and  contractor,  why  are  military  schedules  often 
longer  than  commercial  schedules  for  simulators 
of  comparable  complexity?  The  answer  to  this 
question  is  very  complex.  A  key  factor  is  the 
avail  at i 1 i ty  of  the  aircraft  and  simulated  equip¬ 
ment  data.  This  in  turn  is  followed  by  the 
availability  of  aircraft  parts  and  avionics.  As 
discussed  above,  customer  awareness  and  involve¬ 
ment  in  the  data  and  parts  procurement  has  a 
significant  impact  on  simulator  schedules.  The 
relative  involvement  in  data  and  parts  acquisi¬ 
tion  appears  to  be  a  contributor  to  the  longer 
military  program  schedules. 

Long-lead  Government-screened  MIL-spec  parts 
in  many  instances  become  critical  schedule  path 
items.  For  example,  M[L-spec  connectors  often 
require  a  one-year  or  longer  lead  time,  whereas 
commercial  connectors  are  readily  available.  In 
many  instances,  lead  times  change  and  schedule 
impacts  cannot  be  determined  until  after  the 
parts  selection  and  approval  process  has  been 
completed.  Attempts  to  substitute  at  that  point 
in  the  program  may  relieve  but  usually  do  not 
eliminate  schedule  impacts. 


The  complexity  of  the  simulator  program,  as 
measured  by  the  various  data  items,  meetings, 
correspondence,  etc.,  has  a  major  effect  on  the 
simulator  program  and  thus  its  schedule. 

Summary 

Although  we  have  discussed  the  discriminators 
individually,  in  actual  practice  they  are  all 
blended  together  and  all  interact  simultaneously. 
The  combination  of  all  of  these  elements  results 
in  a  whole  which  is  greater  than  the  sum  of  its 
parts  in  terms  of  program  complexity.  Therefore, 
overall  effectiveness  in  the  acquisition  of  com¬ 
plex  devices  such  as  simulators,  appears  to  be 
greatly  enhanced  by  the  reduction  in  the  number 
and  complexity  of  the  requirements  and  processes. 

EVALUATION  OF  COMMERCIAL  PRACTICES  WHICH  HAVE 
POTENTIAL  APPLICATION  TO  MIL  I  TART  REQUIREMENTS 

In  certain  situations,  many  of  the  approaches 
utilized  in  commercial  procurements  could  be 
selectively  applied  to  procure  simulators  for 
the  military.  As  discussed  previously,  many  of 
the  current  requirements  included  in  the  military 
contracts  are  mandated  by  the  maintenance  support 
concept.  The  various  discriminators  between  the 
two  programs  could  be  put  into  two  categories: 

1)  Those  applicable  only  if  support  con¬ 
cepts  are  changed  to  accommodate  these 
practices  and 

2)  Those  applicable  independent  of  the 
support  concept. 

Prior  to  categorizing  and  discussing  the 
various  key  discriminators,  a  brief  review  of 
the  impact  of  the  support  concept  selection  is 
in  ordur. 

Support  Concept 

The  election  of  an  organic  support  system 
requires  the  Government  to  draw  upon  many  organ¬ 
izations  which  are  geared  to  the  support  of 
expensive,  critical  items  of  equipment  and  the 
missions  that  this  equipment  is  designed  to 
accomplish.  These  organizations  are  essential 
to  ensure  that  the  readiness  of  the  United 
States  defense  is  maintained.  Flight  simula¬ 
tors,  however,  are  heavily  taxed  by  this  system 
and  in  many  instances,  without  practical  justi¬ 
fication.  The  criticality  of  a  simulator  mal¬ 
function,  and  the  criticality  of  instant  repair 
of  the  simulator  is  far  less  important  than  the 
support  of  an  attack  aircraft  in  a  wartime  envi¬ 
ronment.  Moreover,  there  are  fewer  simulators 
than  aircraft  in  the  Government  inventory.  Yet, 
when  the  two  devices  draw  upon  tne  same  suoport 
organizations,  many  of  the  same  requirements  are 


54 


imposed  on  each  procurement  program.  The  reli¬ 
ance  upon  organic  maintenance  personnel  and 
existing  supply  systems  forces  the  Government 
into  an  inefficient  maintenance  concept  for  some 
of  its  equipment.  The  magnitude  of  the  cost 
impact  of  these  basic  policies  depends  upon  the 
size  of  the  program  and  the  extent  to  which  the 
particular  service  is  willing  to  modify  its 
requirements. 

The  direct  cost  of  maintenance  is  only  one 
element  in  the  costs  associated  with  the  choice 
of  the  maintenance  concept.  In  order  to  maxi¬ 
mize  savings  associated  with  the  various 
choices,  selection  of  the  maintenance  concept 
must  take  place  prior  to  issuance  of  an  RFP 
because  overall  program  complexity  is  affected 
dramatically  by  this  decision.  Contractors 
usually  find  it  very  difficult  to  price  various 
alternatives  or  indeed,  to  separate  the  impact 
of  individual  requirements  so  as  to  arrive  at 
costs  that  are  allocated  correctly.  The  cost 
savings  possible  with  contractor  support  can  in 
many  instances  be  demonstrated  without  regard  to 
other  attendant  program  economies  as  was 
recorded  in  a  GAO  report: 

"In  the  mid-70's,  the  Air  Training  Command 
published  the  results  of  a  contract  vs.  in- 
house  cost  comparison  study  in  support  of  T5 
and  T45  (Undergraduate  Navigator  Training 
System  and  Simulator  for  Electronic  Warfare 
Training  System)  navigational  and  tactical 
simulators  used  in  its  undergraduate  train¬ 
ing  program.  Prior  to  the  study,  the 
simulators  were  maintained  by  56  in-house 
personnel.  As  part  of  the  study,  ATC 
solicited  bids  for  contract  maintenance 
support.  The  proposal  by  the  low  bidder, 
who  was  ultimately  awarded  the  contract, 
showed  a  requirement  for  only  26  maintenance 
personnel;  less  than  50%  of  the  in-house 
staff  used  by  ATC  to  maintain  the  simula¬ 
tors.  It  should  be  noted  that  personnel 
costs  represented  approximately  90%  of  total 
support  costs  for  in-house  maintenance."’ 

The  Navy  has  also  recognized  this  fact, 
having  recently  disestablished  the  Training 
Device  Technician  field.  The  support  of  the 
Navy's  existing  inventory  of  aviation  training 
devices  is  being  procured  competitively  from 
private  industry  by  NTEC  not  only  to  take  advan¬ 
tage  of  cost  savings,  but  perhaps  even  more 
importantly,  to  relieve  critical  shortages  of 
technical  skills.  In  this  rase,  the  contractor 
will  be  permitted  to  exercise  the  Government 
supply  system,  with  primary  responsibility  for 
providing  spares  residing  with  the  U.S.  Navy. 

The  contractor  will  be  allowed  to  procure  spares 
if  the  U.S.  Navy  system  cannot  provide  the 
required  spares  in  a  timely  manner.  Existing 
available  support  equipment  will  be  turned  over 
to  the  contractor  who  will  be  responsible  for  any 
replacements  or  additional  equipment.  Documenta¬ 
tion  must  be  kept  current,  and  contractors  must 
meet  Navy  reporting  needs  in  order  that  support 
contracts  may  be  reopened  for  competition  in  the 
future. 

’  GAO  report.  Special  Programs,  Audits 

Division,  Project  8AE-140,  March  26,  1979 


The  use  of  organic  maintenance  to  support 
highly  sophisticated  training  equipment  often 
leads  to  a  series  of  inefficiencies.  Owing  to 
relatively  high  turnover  rates,  ongoing  mainte¬ 
nance  training  is  required.  The  replacement 
technicians  typically  lack  technical  knowledge 
and  as  a  result,  training  courses  must  be  very 
detailed.  Thus,  maintenance  technicians  require 
longer  and  more  expensive  courses  than  are  needed 
for  contractor  personnel.  Further,  the  relative¬ 
ly  low  experience  level  among  available  on-site 
maintenance  personnel  limits  the  type  of  mainte¬ 
nance  which  can  be  performed  on-site.  This  in 
turn  requires  a  different  spares  philosophy,  the 
use  of  depot  repair  and  more  extensive  test 
equipment.  The  higher  skill  level  of  contractor 
personnel  allows  better  use  of  available  person¬ 
nel  and  permits  cross-training  so  that  individ¬ 
uals  can  maintain  multiple  areas  of  the  trainer. 
An  important  factor  resulting  in  higher  contrac¬ 
tor  support  efficiency  is  that  non-productive 
personnel  can  be  eliminated  from  the  site, 
allowing  a  better  motivated  team. 

Pi scrimi nators  Dependent  on  the  Support  Concept 

There  are  certainly  situations  where  organic 
maintenance  should  be  continued.  However,  poten¬ 
tial  savings  in  the  use  of  contractor  maintenance 
should  be  considered  in  selecting  the  support 
concept  on  new  simulator  programs.  In  addition 
to  the  cost  savings  associated  with  the  mainte¬ 
nance,  the  following  major  program  requirements 
should  be  considered  for  elimination. 

Materials,  Parts,  Processes.  The  use  of  M1L- 
spec  parts,  parts  screening,  controlled  manufac¬ 
turing  standards  and  other  associated  require¬ 
ments  is  currently  made  necessary  by  the 
logistics  system  supporting  the  maintenance 
function.  Their  impact  on  program  cost  and 
schedule  (discussed  in  the  previous  section)  is 
considerable,  and  accordingly  these  requirements 
should  be  considered  as  possibly  expendable. 

The  Government  now  permits  the  use  of  certain 
commercially  available  off-the-shelf  equipment 
in  all  procurements.  As  an  example,  commercially 
available  computers  and  CRT  display  systems  are 
not  only  permitted,  but  required  to  be  supplied 
as  part  of  the  simulation  equipment.  This  as¬ 
sures  the  Government  of  the  latest  technology 
with  lowest  cost  and  good  support.  Yet  this 
selection  requires  the  very  compromises  that  are 
being  advocated  here  --  that  is,  the  use  of  com¬ 
mercial  components,  commercial  standards  in 
design  and  manufacturing,  and  most  important  the 
willingness  to  accept  standardization  and  reduced 
involvement  in  the  design  process.  Another  exam¬ 
ple  is  the  use  of  commercially  available  and 
demonstratable  visual  systems.  Here  again,  the 
Government  is  willing  to  waive  MIL-spec  require¬ 
ments  in  exchange  for  the  benefits  of  the  reduced 
cost  and  schedule. 

The  substitution  of  a  contractor  parts  con¬ 
trol  program  (without  Government  involvement) 
would  remove  many  data  items  and  other  obstacles 
to  the  performance  of  the  program.  The  use  of 
cormercial  approaches  to  design  and  manufacture 
opens  the  door  to  existing  design  and  its  attend¬ 
ant  benefits.  Considering  that  the  training 
equipment  is  ground-based,  and  that  some  of  the 
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main  portions  of  the  simulator  are  permitted  to 
be  unaltered  commercial  items,  does  it  make  sense 
to  require  Mil-spec  parts  and  processes  for  those 
pieces  designed  and  built  by  the  simulator  manu¬ 
facturer? 


ings  and  in  addition,  maintain  (control,  file, 
etc.)  them  in  its  system.  Commercial  customers 
require  only  the  drawings  necessary  for  mainte¬ 
nance  in  the  commercial  format  and  find  their 
requirements  satisfied  at  much  lower  costs. 


Logistics  Data.  Approximately  30  data  items 
were  required  on  the  C-130E  program  to  support 
the  purchase  and  dispositioning  of  the  spares 
and  support  equipment  necessary  for  organic 
maintenance.  This  is  in  addition  to  the  signi¬ 
ficant  investment  required  for  the  purchase  of 
the  items.  Substantial  numbers  of  Government 
personnel  were  involved  in  the  process  of  eval¬ 
uating  and  procuring  the  spares  as  well  as 
statusing  and  handling  them.  The  cost  to  the 
Government  of  applying  the  logistics  concepts  to 
the  C-130  simulator  program  may  very  weil  have 
exceeded  the  cost  of  the  design,  production, 
test,  and  installation  of  the  device. 

In  contrast,  the  spare  parts  for  commercial 
simulators  are  identified  using  existing  engi¬ 
neering  bill  of  material  listings  without  the 
specific  provisioning  documents  being  generated 
for  current  00D  programs.  Similarly,  satisfac¬ 
tory  support  analyses  are  performed  on  commer¬ 
cial  contracts  without  the  costly  documentation 
(e.g..  Logistics  Support  Analysis  Record)  re¬ 
quired  in  an  organic  program.  Thus,  if  there  is 
no  need  to  use  the  Government  supply  system,  sig¬ 
nificant  savings  can  result  by  eliminating  many 
costly  requirements. 

Design  Documentation.  The  level  of  design 
documentation  is  directly  attributable  to  the 
support  concept.  The  software  documentation 
required  by  current  military  programs  typically 
can  exceed  350,000  pages  in  length!  The  documen¬ 
tation  is  geared  to  entry-level  maintenance  tech¬ 
nicians  who  are  unfamiliar  with  the  equipment, 
so  that  the  documents  become  in  effect  training 
manuals.  Further,  the  level  of  documentation  is 
required  to  support  any  subsequent  change  activ¬ 
ity  by  a  maintenance  team  with  little  experience. 
Consequently,  the  detail  required  is  extensive. 

In  contrast,  commercial  documentation  provides  an 
understanding  of  the  system  simulated  and  the  ap¬ 
proaches  utilized  in  obtaining  the  desired  simu¬ 
lation.  The  advent  of  higher-order  languages 
such  as  Fortran  has  eased  the  documentation  re¬ 
quirements,  since  capable  programmers  can  under¬ 
stand  the  software  by  reviewing  the  coding  state¬ 
ments  and  appropriate  commentary.  The  commercial 
customers  routinely  maintain  and  perform  minor 
updates  without  difficulty  utilizing  the  commer¬ 
cial  level  of  documentation.  The  cost  of  the 
military  documentation  and  its  disruptive  impact 
on  the  development  programs  is  overwhelming.  A 
considerable  cost  savings  could  be  realized  if 
this  requirement  were  relaxed.  The  use  of  a 
contractor  support  system  would  permit  this  to 
happen. 

Similarly,  the  level  of  detail  required  in 
the  drawing  packages  is  far  greater  in  military 
contracts.  The  formats  of  the  drawings  are  more 
restrictive  and,  in  addition,  lower  levels  of 
drawings  are  required  to  be  submitted.  Presum¬ 
ably  this  is  to  permit  flexibility  in  second- 
source  selection  (which  rarely  happens  in 
simulators)  and  provide  assurance  that  spare 
parts  could  be  manufactured  by  the  Government  if 
necessary.  The  Government  must  pay  for  the  draw¬ 


Conf iguration  Control.  A  favorite  topic  of 
discussion  in  today's  procurement  arena  is  con¬ 
figuration  control.  Most  simulator  manufac¬ 
turers  have  demonstrated  hardware  configuration 
control  systems  which  meet  both  military  and 
commercial  requirements  and  adequately  ensure 
that  replacement  parts  can  be  procured  so  that 
they  are  form,  fit,  and  function  interchange¬ 
able.  Software  configuration  control,  which 
includes  both  the  instruction/data  code  and 
documentation,  is  a  subject  of  current  concern 
because  the  Government  wants  assurance  that  the 
final  product  not  only  results  in  the  proper 
simulator  performance,  but  also  is  exactly  docu¬ 
mented  so  that  it  can  be  understood  and/or 
changed  as  required.  The  controls  imposed  by 
the  Government  therefore  are  very  rigorous  and 
in  some  ways  constraining. 

A  problem  arises  in  the  simulation  business 
because  software  is  constantly  being  changed 
during  the  design,  test,  and  customer  acceptance 
periods.  The  need  for  software  conf iguration 
control  is  a  well-founded  and  accepted  require¬ 
ment.  On  commercial  simulator  programs,  systems 
are  employed  which  provide  insight  into  the  exact 
revision  level,  date  last  changed,  check-sum, 
etc.,  of  software  modules  in  a  very  efficient 
manner,  without  automatically  tying  the  software 
documentation  into  the  control  system.  Most  of 
the  risk  of  out-of-date  documentation  disappears 
because  the  documentation  is  less  complex  and/or 
detailed.  The  risk  is  then  minimized  by  documen¬ 
tation  updates  upon  completion  and  acceptance  of 
the  software  rather  than  in  a  concurrent  inode. 

The  efforts  associated  with  very  rigorous 
software  configuration  control  systems  are  very 
costly  and  adversely  affect  productivity.  Since 
commercial  simulators  are  routinely  designed, 
delivered,  and  maintained  without  this  rigor,  and 
without  significant  problems,  serious  consider¬ 
ation  should  be  given  to  the  use  of  contractor 
maintenance  and  an  attendant  relaxation  of  the 
software  configuration  control  requirements. 

Manual s .  The  relatively  low  experience  level 
of  the  available  on-site  maintenance  personnel, 
coupled  with  their  high  turnover  rate,  causes 
the  imposition  of  a  requirement  to  write  tech¬ 
nical  orders  to  accommodate  that  skill  level. 
Little  or  no  pre-existing  knowledge  can  be 
assumed.  In  addition,  military  technical  publi¬ 
cation  standards  regarding  format,  artwork,  and 
materials  result  in  significantly  more  expensive 
manuals  which  contain  essentially  the  same  data 
as  those  procured  according  to  standard  commer¬ 
cial  practices.  Thus,  if  contractor  maintenance 
is  employed,  considerable  savings  can  be  realized 
by  the  reduction  in  requirements  associated  with 
the  generation,  verification,  and  validation  of 
manuals. 

Spares/Support  Equipment.  The  cost  of  spares 
and  support  equipment  on  a  military  program  far 
outweighs  the  equivalent  requirements  on  a  com¬ 
mercial  program.  Because  of  the  remove-and-re- 
place  maintenance  philosophy  employed,  repair  of 
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the  Equipment  Replacement  Units  (ERU's)  must  be 
done  at  the  depot  level.  In  commercial  applica¬ 
tions,  contractor  personnel  normally  perform  the 
majority  of  ERU  repair  on  site.  As  can  be  demon¬ 
strated  using  any  support  cost  model,  a  depot 
repair  philosophy  results  in  a  significantly 
higher  spares  procurement  at  the  ERU  level. 

This  repair  philosophy,  in  turn,  necessitates 
the  purchase  of  sophisticated  test  equipment  to 
fault-isolate  failed  units  and  to  verify  their 
repair.  Where  on-site  repair  is  possible,  the 
simulator  itself  in  most  cases  can  be  used  for 
this  purpose  during  the  maintenance  period. 


Because  the  military  requires  that  its  exist¬ 
ing  supply  systems  be  employed  to  support  the 
simulators  it  procures,  simulator-unique  equip¬ 
ment  is  entered  into  the  national  stock  numbering 
system  at  a  cost  of  approximately  $5,000  per  part 
number  over  the  life  of  the  trainer.  In  addi¬ 
tion,  the  base  supply  system  adds  another  $500 
annually  per  part  number  per  site.  The  AFLC 
Logistics  Support  Cost  Model  indicates  that  in¬ 
ventory  management  is  second  only  to  spares  as 
the  leading  support  cost  driver.  Similarly, 
support  equipment  procurement  and  management  is 
cumbersome  when  utilizing  the  logistics  systems. 

The  commercial  simulators  are  adequately  sup¬ 
ported  with  far  fewer  spares  and  support  equip¬ 
ment  and  with  less  involvement  from  depot  or 
equivalent.  As  noted  earlier,  American  Airlines 
in  support  of  its  767  simulator  invested  signifi¬ 
cantly  less  than  the  amount  invested  by  the 
Government  for  the  C-130E.  In  many  cases,  even 
with  less  investment,  the  avoidance  of  the  depot 
system  translates  into  fewer  delays  and  downtime 
and  thus  better  equipment  availability.  Thus, 
the  concept  of  a  dedicated  complement  of  spares 
and  support  equipment,  which  is  feasible  with 
contractor  support,  offers  the  opportunity  for 
significant  cost  savings  without  degradation  of 
simulator  availability. 


Discriminators  Independent  of  Support  Concept 


Many  current  military  procurement  practices 
could  be  brought  into  alignment  with  commercial 
practices  as  a  method  of  cost  reduction  even 
while  maintaining  the  organic  support  concept. 
The  following  paragraphs  discuss  the  items 
which,  if  adopted,  could  either  stand  alone  or 
represent  additional  savings  to  those  dependent 
upon  the  use  of  contractor  support. 


Customer  Involvement.  The  military  procure¬ 
ments  require  a  high  degree  of  customer  involve¬ 
ment  in  all  aspects  of  the  conduct  of  the  pro¬ 
gram.  This  involvement  complicates  the  manage¬ 
ment  function  and  in  many  cases  adds  to  technical 
complexity  during  the  design  process.  It  affects 
the  performance  of  the  contract  and  is  one  of 


the  most  significant  factors  attributing  to  the 
difficulty  in  maintaining  schedule.  This  in¬ 
volvement  is  apparent  in  the  need  for  the  sub¬ 
mission  of  data  items  like  the  Configuration 
Management  Plan,  Detailed  Human  Engineering 
Plan,  Personnel  Subsystem  Test  and  Evaluation 
Plan,  Hazard  Analysis  Report,  Transportability 
Report,  Reliability/Maintainability  Demonstra¬ 
tion  Plan,  System  Safety  Program  Plan,  System 
Test  Plan,  Technical  Manual  Plan,  and  the 
Integrated  Support  Plan.  In  addition,  many 
design  reviews  and  status  meetings  are  required 


with  relatively  large  numbers  of  attendees.  The 
commercial  approach  of  minimal  involvement  after 
selection  of  a  competent  manufacturer  permits 
the  contractor  to  concentrate  on  designing  and 
building  the  simulator.  This  topic  has  been 
discussed  in  workshops  with  contractor  and 
Government  personnel  and  the  word  "micro- 
management"  has  been  coined  to  express  the 
current  approach.  One  possible  solution  worthy 
of  consideration  is  an  extension  of  what  the 
Government  currently  does  in  the  proposal 
evaluation  period. 

Major  U.S.  Air  Force  procurements  managed  by 
Aeronautical  Systems  Division  (ASD)  require 
examination  of  the  contractor's  capabilities  via 
an  MM/PCR  (Manufacturing  Management/Production 
Capability  Review)  before  contract  award.  If 
this  were  extended,  either  on  a  per-contract 
basis  or  on  a  periodic  basis,  to  certify  the 
contractor's  capability  and  procedures  in  many 
of  the  above  areas,  each  contract  would  be  re¬ 
lieved  of  the  redundant  submittals,  revisions, 
and  discussions  associated  with  each  item.  This 
would  give  the  Government  assurances  (perhaps 
along  with  DCAS  monitoring)  that  the  processes 
being  employed  by  the  company  are  sound,  without 
injecting  undue  interference.  Similarly,  a 
lesser  involvement  in  the  design  review  process 
would  in  effect  eliminate  many  instances  of  spe¬ 
cifying  "how"  a  certain  requirement  is  to  be 
met.  Going  a  step  further,  adoption  of  the  com¬ 
mercial  practice  of  much  higher-level  status 
reporting  would  eliminate  the  need  of  many  addi¬ 
tional  reports  and/or  meetings  which  compound 
the  program  complexity  and  disrupt  program 
operations. 

Certainly,  the  military  procurement  agencies 
as  they  exist  today  could  not  accept  these  sug¬ 
gestions  without  considerable  change  in  the  way 
the  Government  does  business.  The  expanded  use 
of  firm  pricing  in  conjunction  with  bonuses  or 
penalties  as  is  done  on  some  commercial  con¬ 
tracts,  would  alleviate  many  of  the  Government's 
misgivings.  This  pricing  philosophy  would  more 
firmly  place  the  burden  of  performance  on  the 
contractor,  but  would  only  be  successful  if  the 
contractor  is  given  the  freedom  to  manage  the 
program  wi thout  undue  interference.  Another 
possible  change  would  require  reorganizing  the 
procurement  team  in  such  a  way  that  decisions 
could  be  made  by  key  individuals  rather  than  by 
committee.  This  would  considerably  reduce  the 
cost  of  the  Government's  procurement  team  and 
also  streamline  the  program  from  the 
contractor's  viewpoint. 

The  quality  of  the  product  is  not  necessarily 
improved  by  the  current  high  level  of  attention 
and  scrutiny  exercised  by  the  Government.  Com¬ 
mercial  simulators  produced  under  less  rigorous 
conditions  .of  customer  supervision  are  highly 
acceptable  training  devices  and  deliver  excellent 
transfer  of  training  capability.  Therefore,  the 
commercial  method  of  managing  the  procurement 
should  be  closely  analyzed  for  applicability  to 
the  military  procurement  programs. 

Acceptance  Approach.  The  approach  used  by 
the  military  in  accepting  a  simulator  is  far 
more  demanding  than  that  employed  by  the  com¬ 
mercial  customers.  The  acceptance  approach 
differences  center  on  the  size  of  the  ATP,  the 
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method  of  evaluating  subjective  areas  and  the 
size  and  continuity  of  the  test  team.  The  size 
of  the  typical  military  ATP  and  the  method 
employed  in  subjectively  evaluating  the  simu¬ 
lator  reflect  on  the  Government's  desire  to 
accept  the  training  device  only  after  it  is  "per¬ 
fect,"  minimizing  the  risk  that  a  requirement 
was  missed  or  a  defect  was  left  undiscovered. 

To  achieve  this  aim,  a  large  acceptance  team  is 
deployed,  which  not  only  identifies  valid 
problems,  but  frequently  injects  disruption  and 
in  some  cases  confusion  to  the  acceptance  pro¬ 
cess.  Lessons  learned  from  the  commercial 
practices  suggest  that  the  test  team  be  reduced 
to  as  few  members  as  possible.  Additionally, 
the  use  of  warranty  and  updates  to  correct  prob¬ 
lems  found  after  acceptance  could  alleviate  the 
anxieties  and  risk  associated  with  the  Govern¬ 
ment's  "single-  shot"  approach  currently  prac¬ 
ticed  at  acceptance. 

Another  problem  associated  with  customer 
acceptance  of  flight  simulators  is  the  "tailor¬ 
ing"  that  is  required  to  make  the  simulator 
subjectively  fly  like  the  aircraft  or  operate 
like  the  equipment.  Many  times,  the  requested 
changes  are  not  supported  by  aircraft  data  or 
training  need.  Because  of  the  nature  of  these 
requested  changes,  contractors  usually  object  to 
the  continuation  of  extensive  testing/  changing 
in  these  areas. 

The  commercial  approach  is  to  ascertain  that 
the  test  guides  are  met  to  the  customer's  satis¬ 
faction.  Then  a  specified  period  is  allocated 
to  the  subjective  tailoring  process.  In  some 
instances  this  period  is  exceeded,  but  relative¬ 
ly  speaking,  the  program  proceeds  as  planned  and 
scheduled  while  accommodating  the  crew  inputs. 

In  this  case,  crew  experience  and  consistency 
are  paramount,  as  well  as  the  commercial  under¬ 
standing  that  al 1  aircraft  of  a  given  type  do 
not  perform  exactly  alike.  By  open  recognition 
of  the  requirement  for  subjective  adjustments 
and  by  allocating  a  certain  period  of  time  for 
their  accomplishment,  a  teamwork  approach  is 
typically  adopted.  This  usually  results  in 
excellent  results  for  both  the  contractor  and 
the  customer.  The  acceptance  process  used  on 
commercial  programs  is  directly  applicable  to 
the  military  programs  with  minor  procurement 
practice  changes  required,  and  it  should  be 
considered. 

Aircraft  Data  and  Parts  Management.  The 
methods  employed  by  both  military  and  commercial 
procurement  practices  for  the  management  of 
aircraft  data  and  parts  can  dramatically  affect 
program  schedules.  It  would  be  very  much  to  the 
Government's  advantage  to  become  involved  in  the 
process.  As  noted  in  the  discussion  on  conmer- 
cial  practices,  some  airlines  elect  not  to 
assume  responsibility  for  parts  or  data  acqui¬ 
sition,  but  they  nonetheless  actively  partici¬ 
pate  in  obtaining  parts  and  data  for  the  con¬ 
tractor  In  the  Interest  of  their  program.  When 
individual  airlines  are  unsuccessful  in  persuad¬ 
ing  the  aircraft  or  avionics  manufacturers  to 
cooperate  In  procurement,  they  often  achieve 
their  aims  by  lobbying  through  such  organiza¬ 
tions  as  the  Air  Transport  Association  (ATA)  or 
the  International  Air  Transport  Association 
(IATA).  The  military  procurement  agencies 
should  at  least  take  an  active  role  (preferably 
full  responsibility)  in  this  area  because  parts 


and  data  are  always  on  the  critical  path  of  a 
program.  Government  involvement  in  this  area 
will  make  a  difference.1 

Concurrent  Change  Control.  The  ability  of  a 
commercial  simulator  to  be  concurrently  updated 
with  the  aircraft  during  the  design,  manufactur¬ 
ing,  and  test  phases  of  a  contract  is  very 
important  to  the  customer  in  ensuring  prompt 
availability  of  a  simulator  which  accurately 
reflects  the  aircraft.  This  process  is  seldom 
duplicated  on  military  programs  because  of  the 
rigidity  of  the  procurement  process  and  the  com¬ 
plexity  of  simulator  programs.  But  there  are 
isolated  exceptions:  some  complex  military  simu¬ 
lation  devices  were  produced  during  the  develop¬ 
ment  of  the  operational  hardware  and  configura¬ 
tion  updates  occurred  in  parallel.  NASA,  in 
development  of  the  Apollo  and  LEM  spacecraft 
simulators,  ensured  that  the  critical  simulators 
were  designed  to  the  latest  baseline  with  updates 
taking  place  throughout  the  simulator  program. 

The  NASA  program  management  and  engineering  teams 
(both  NASA  and  the  contractor)  worked  together  as 
a  close  team.  Key  individuals  were  given  author¬ 
ity  and  key  decisions  were  made  when  they  were 
needed.  The  support  concept  (contractor  support) 
permitted  these  highly  critical  programs  to  be 
conducted  in  a  manner  which  concentrated  on 
proper  execution  of  design  and  testing  and  placed 
less  emphasis  on  the  supporting  data  and  loqis- 
tics  considerations.  This  approach  not  only  sup¬ 
ported  the  schedule,  but  directly  influenced  the 
cost,  since  the  streamlined  methods  positively 
influenced  production  efficiency. 

The  benefits  to  the  user  of  concurrent  change 
activity  are  not  only  desirable,  but  achievable. 
The  Government  must  weigh  the  potential  benefits 
against  the  potential  impact  of  changes  which 
would  have  to  be  made  in  procurement  practices. 

A  contractor  support  system  (and  the  attendant 
reduction  of  program  requirements)  would  provide 
an  ideal  foundation  for  concurrent  change  activ¬ 
ity.  Even  so,  changes  in  the  procurement  prac¬ 
tice  (permitting  nearly  instantaneous  decisions 
and  authorizations  to  proceed  without  laborious 
proposal  submittal  and  evaluation)  are  the  key 
to  improving  the  process  in  a  substantial  and 
meaningful  way. 

CONCLUSIONS  AND  RECOMMENDATIONS 
FOR  FUTURE  CONSIDERATION 

Many  commercial  procurement  practices  can  be 
applied  to  selective  military  programs;  as  this 
paper  has  attempted  to  demonstrate,  these  tech¬ 
niques  do  not  offer  a  total  solution  to  all  mil¬ 
itary  procurements,  but  they  do  present  alterna¬ 
tives  which  in  some  instances  provide  a  capabil¬ 
ity  to  reduce  life-cycle  costs  and  to  shorten 
schedules. 

Adopt  Contractor  Support  Concept 

The  single  most  important  procurement  prac¬ 
tice  to  consider  is  the  extensive  use  of  con¬ 
tractor  support,  a  practice  which  can  be  fully 
justified  when  its  costs  are  compared  to  the 
cost  of  organic  support.  Perhaps  even  more  sig¬ 
nificant  is  the  fact  that  the  support  concept 
dictates  the  other  program  requirements.  The 
selection  of  contractor  maintenance  opens  the 
door  for  a  complete  re-evaluation  of  these 
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requirements.  Because  commercial  airlines  can 
operate  their  equipment  with  a  fraction  of  the 
documentation  and  supporting  material  that  is 
required  by  the  Government,  it  seems  entirely 
reasonable  for  the  Government  to  consider  emu¬ 
lating  this  approach  where  not  constrained  by 
environmental  factors. 


Structure  Program  Requirements  To  Reflect  Support 
Concept. 


If  contractor  support  is  selected  on  a  new 
procurement,  the  program  requirements  should  be 
restructured  to  eliminate  unnecessary  items. 

The  requirements  for  spare  parts,  support  equip¬ 
ment,  software  documentation,  drawings,  logis¬ 
tics  data,  and  manuals  all  need  to  be  re¬ 
evaluated  carefully.  Strong  consideration 
should  be  given  to  requiring  only  those  items 
necessary  for  the  contractor  to  maintain  the 
equipment,  as  defined  by  the  contractor.  These 
items  can  be  easily  reviewed  to  ensure  that  the 
option  is  preserved  to  recompete  the  support 
contract  in  the  future.  The  reduction  of 
requirements  would  not  only  reduce  the  pro¬ 
curement  costs,  but  would  streamline  the 
simulator  development  and  reduce  the  risk  of 
schedule  and  cost  overrun.  The  potential  for 
further  schedule  reduction  is  also  possible, 
depending  on  the  extent  of  the  reduction  in 
program  requirements. 

Another  key  change  feasible  under  a  contract¬ 
or  support  concept  is  the  elimination  of  the 
restriction  imposed  on  materials,  parts,  and 
processes.  The  use  of  good  commercial  practices 
in  these  areas  will  not  degrade  the  performance 
of  the  simulator  in  its  mission  of  training  crew 
members.  There  is  no  reason  to  differentiate 
between  an  off-the-shelf  computer  complex  with 
its  many  printed-circuit  cards,  and  a  simulator 
manufacturer's  specially  designed  printed-circuit 
cards.  Simulator  manufacturers  have  proven  the 
excellent  quality  and  supportability  of  their 
product  for  many  years. 


Adopt  Commercial  Program  Practices 


Military  procurement  practices  impose  many 
restrictions  which  may  not  be  necessary  to  con¬ 
trol  the  development  of  ground-base  training 
equipment.  Consideration  should  be  given  to  the 
possibility  of  adopting  those  commercial  ap¬ 
proaches  which  result  in  a  more  hands-off  atti¬ 
tude  (after  careful  selection  of  a  qualified 
simulator  manufacturer).  Certain  safeguards 
(warranty,  updates,  etc.),  as  used  in  the  commer¬ 
cial  procurements,  could  be  employed  so  as  to 
minimize  risk.  The  reduction  in  procurement  and 
life-cycle  costs  will  far  outweigh  the  risks; 
most  important,  the  objectives  of  reduced  costs 
and  shorter  schedules  can  be  more  readily  at¬ 
tained.  Consideration  should  also  be  given  to 
the  elimination  of  the  various  program  plans  and 
a  reduction  in  the  number  of  formal  design  and 
program  review  meetings.  Certification  of  the 
company's  procedures  and  capabilities  could  be 
considered  as  a  way  of  ascertaining  the  compe¬ 


tence  of  the  contractor.  These  requirement 
reductions  would  not  only  reduce  the  contract 
costs,  but  the  procurement  team  costs  as  well. 

The  methodology  of  commercial  customer  ac¬ 
ceptance  should  be  evaluated  and  adopted  where 
feasible.  This  would  require  a  change  in  the 
acceptance  philosophy  and  would  probably  need  to 
be  supported  by  a  "product  champion"  who  is  able 
and  willing  to  make  decisions  readily.  Again 
risks  could  be  minimized  by  specifying  certain 
periods  for  performance  updates  in  the  future  to 
correct  deficiencies  and  by  the  use  of  warranty 
to  cover  latent  defects. 

Government  involvement  in  the  timely  avail¬ 
ability  of  aircraft  parts  and  data  management 
would  provide  an  opportunity  to  reduce  critical 
path  lead  times.  This  could  be  done  partially 
without  any  additional  Government  responsibility 
or  risk,  and  should  be  strongly  considered. 

The  ability  to  provide  simulator  configura¬ 
tions  matcning  the  customer's  operational  needs 
requires  careful  planning  and  prompt  decisions. 
Streamlining  the  procurement  decision  process, 
as  well  as  becoming  willing  to  make  these  deci¬ 
sions  without  extensive  documentation  (as  in 
commercial  practice)  will  result  in  a  more 
usable  simulator. 

In  conclusion,  the  military  and  commercial 
simulator  procurement  methods  are  quite  dif¬ 
ferent  and  result  in  wide  variance  of  costs, 
schedules,  and  program  complexities.  The  ap¬ 
plication  of  commercial  practices  does  seem 
feasible  if  certain  changes  are  made  in  the 
support  concept  and  on  the  part  of  the  pro¬ 
curement  team. 

There  seems  to  be  no  doubt  whatever  that 
cost-effectiveness  and  training  effectiveness 
(through  earlier  availability  of  equipment)  may 
be  strongly  augmented  by  adoption  of  some,  any 
or  all  of  the  reconmendatlons  suggested  here, 
and  they  should  be  fully  exploited. 
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ABSTRACT 

The  benefits  associated  with  combat  crew  readiness  are  obvious  What  may  not  be  so  obvious  are  the  benefits  associated 
with  timely  acquisition  and  availability  of  training  and  training  devices.  As  new  aircraft  programs  develop  and  present  aircraft 
programs  mature,  the  crews  must  either  train  on  the  operational  equipment  or  wait  until  the  associated  trainers  are 
developed  or  updated.  If  the  trainers  are  developed  and  updated  in  concert  with  the  aircraft  program,  the  Air  Force  is 
provided  not  only  with  combat-ready  crews  at  the  .  rrect  time,  but  also  at  the  correct  cost.  The  key  to  keeping  the  training 
devices  in  concert  with  the  aircraft  is  a  Concurrency  Program 

On  the  B-1B  program,  a  complete  concurrency  program  is  being  addressed.  By  complete,  it  is  meant  a  program  which 
addresses  the  two  maior  issues  associated  with  keeping  the  trainer  concurrent  with  the  aircraft: 

1.  Cost-effective  development  and  distribution  of  the  required  design  criteria  data. 

2  Inherent  flexibility  designed  into  the  training  device  to  accommodate  changes  in  a  cost-effective  manner. 


The  benefits  associated  with  combat  crew  readiness  are  obvious. 
What  may  not  be  so  obvious  are  the  benefits  associated  with  timely 
acquisition  and  availability  of  training  and  training  devices.  According 
to  the  1982  Defense  Science  Board  Summer  Study  in  their  briefing 
report  for  training  and  training  technology,  Training  devices  tend  to 
be  acquired  too  late  to  meet  weapon  system  IOC,  in  some  cases  as 
much  as  by  several  years  For  new  training  devices  to  be  of 
greatest  benefit  to  the  weapon  system  they  support,  the  training 
system  should  be  in  place  at  least  by  the  time  the  weapon  system  is 
fielded."  As  new  aircraft  programs  develop  and  present  aircraft 
programs  mature,  the  crews  must  either  train  on  the  operational 
equipment  or  wait  until  the  associated  trainers  are  developed  or 
updated.  If  the  trainers  are  developed  and  updated  rn  concert  with  the 
aircraft  program,  the  Air  Force  is  provided  not  only  with  combat-ready 
crews  (Figure  1)  at  the  correct  time,  but  also  at  the  correct  cost  The 
key  to  keeping  the  training  devices  in  concert  with  the  aircraft  is  a 
Concurrency  Program. 

Concurrency,  as  opposed  to  currency,  incorporates  a  program 
approach  whereby  the  trainer  is  developed  and  delivered  to  a 
specified  schedule  in  concert  with  the  weapon  system  Currency  deals 
with  maintaining  configuration  of  the  training  device,  after  delivery,  to 
coincide  with  the  weapon  system 

As  an  example,  the  757/767  flight  simulators  currently  in  use  at  the 
Boeing  Flight  Training  Center  were  developed  concurrently  with  the 
aircraft  (Figure  2).  This  program  emphasized  the  importance  of 
extensive  interaction  between  the  customer  and  the  simulator 
contractor  to  identify  and  jointly  resolve  design  criteria  issues 

Similarly,  we  are  contracted  to  provide  flight  simulators  for  the 
E-3A/KE-3A  Flight  Crew  Training  system  program  prior  to  the  first 
aircraft  delivery 

The  B-1B  program,  shown  in  Figure  3.  is  where  both  concurrency 
and  currency  are  addressed  Because  of  the  complexity  of  this 
weapon  system  and  the  magnitude  of  potential  changes,  it  is  an 
example  of  a  program  which  must  address  the  two  major  issues 
associated  with  keeping  the  trainer  current  with  the  aircraft: 

1 .  Cost-effective  development  and  distribution  of  the  required 
design  criteria  data 

2  Inherent  flexibility  designed  into  the  training  device  to 
accommodate  changes  in  a  cost-effective  manner 


The  first  feature  is  a  joint  responsibility  of  the  contractor  and  'he 
government  to  provide  the  correct  contractual  and  management 
framework  necessary  to  have  the  right  design  data  at  the  right  time 

The  second  feature  is  a  contractor  responsibility  to  design  flexibility 
into  the  trainer  and  a  government  responsibility  to  specify  the 
requirement  in  the  initial  procurement 

Development  and  Distribution  of  Design  Criteria  Data 

Ideally,  the  plan  for  the  development  and  distribution  of  the  trainer 
design  criteria  data  will  be  inherent  in  the  plan  of  the  weapon  system 
itself.  Specifically,  the  weapon  system  contract  is  constructed  to 
contain  the  requirement  to  develop  and  document  all  data  necessary 
to  faithfully  simulate  the  weapon  system.  A  contractual  framework  is 
thus  provided  for  timely  supplied  data  as  well  as  for  the  weapon 
system  designers  to  provide  data  interpretation  to  ensure  both 
completeness  and  accuracy  Data  of  interest  would  be  delivered  from 
design  reviews,  engineering  tests,  and  flight  tests.  This  approach  to 
source  data  acquisition  is  instrumental  in  a  concurrency  program  and 
desirable  in  a  currency  program. 

Typically,  however,  the  weapon  system  development  is  maturing 
when  the  simulator  program  is  commencing.  In  this  situation,  a  good 
currency  program  can  be  implemeted  by  incorporating  the  following 
items: 


1.  Contractual  agreements  between  simulator  and  aircraft 
contractors  to  provide  continuing  access  to  aircraft 
configuration  data  and  change  activity 

2.  A  design  criteria  management  process  which  provides 
identification  and  configuration  tracking  of  design  criteria 
sufficient  to  accomplish  the  simulator  system  design 

3.  Means  to  establish  and  track  the  traceability  between 
simulator  subelements  and  the  design  criteria  using  a  Data 
Base  Management  System  (DBMS) 

4.  Extensive  customer/simulator  contractor  interaction  to 
identify  verifiable  configurations  and  to  resolve  problems 
arising  from  inconsistencies  and  inadequacies  in  the 
available  design  criteria 
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Figure  1  Concurrency  of  Design  Criteria  -  A  Key  to  Trainer  Readiness 
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Figure  3  B-1B  Aircraft  Simulator  Concurrency 


These  items,  properly  staffed  and  implemented,  provide  the 
simulator  contractor  with  the  necessary  tools  and  design  criteria  to 
maintain  currency  with  the  weapon  system  For  this  currency  to  be 
cost  effective,  the  simulator  contractor  must  go  one  step  further  and 
design  a  device  which  possesses  inherent  flexibility  for 
accommodating  weapon  system  updates 

Inherent  Simulator  Flexibility  for  Weapon  System  Changes 

The  concurrent  development  of  the  aircraft  and  simulator  systems 
causes  design  criteria  to  be  based  on  the  aircraft  configuration 
expected  at  the  time  of  simulator  deployment  Since  a  large  amount  of 
the  initial  simulator  design  will  occur  without  the  availability  of 
complete  flight  test  and  technical  order  data,  it  will  be  necessary  to 
work  with  predicted  aircraft  performance  and  preliminary  design  data 
while  planning  for  inclusion  of  more  detailed  data,  especially  from 
flight  test,  as  well  as  from  other  areas  of  weapon  system  updates 

This  ongoing  refinement  of  the  weapon  system  design  places  an 
additional  requirement  on  the  simulator  -  namely  to  easily 
accommodate  updates  in  the  design  baseline  As  shown  in  Figure  4. 
the  B-tB  is  an  example  of  such  a  weapon  system  A  flexibility 
approach  to  each  weapon  system  change  area  (see  Figure  5)  is 
examined  below 


Figure  4  B-1B  Weapon  System  Change  Areas 

1 .  Operational  Flight  Program  Updates  -  to  increase 
flexibility  in  this  area,  the  simulator  should  be  designed  so 
as  to  directly  compile  the  aircraft  operational  flight 
programs  (OFPs)  without  the  need  of  recoding  by  software 
engineers  Examples  of  simulator  designs  providing  this 
flexibility  include:  emulation  of  the  on-board  processors, 
cross-compiling  of  the  OFPs,  and  use  of  the  on-board 
processor  in  simulation. 

2.  Weapon  System  Changes  -  several  features  can  be 
incorporated  into  the  simulator  to  minimize  the  impact  of 
weapon  system  changes  These  features  include: 


accommodate  quite  easily  the  changes  in  the  jARM 
(Jammer,  Artillery.  Radar  or  Missile)  environment  For 
example,  a  modular  program  for  jamming  which 
determines  jamming  effectiveness  from  a  data  table  using 
jamming-to-signal  ratio,  can  accommodate  new  power 
densities  and  new  frequencies  based  on  data  changes 
only 
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Figure  5  A  Simulator  Flexibility  Approach 


a.  A  modular  software  approach  to  provide 
straightforward  identification  and  isolation  of  changes 
to  software  elements 

b.  Modeling  approaches,  such  as  data-driven  models, 
which  increase  simulator  update  efficiency 

c.  A  modular,  data-driven  linkage  interface  system 
which  permits  the  simulator  to  accommodate 
control/display/instrument  changes  with  minor 
interface  system  impact 

3,  Electromagnetic  Environment  Changes  -  again 
modularized  software  which  is  table  data-driven  can 


In  addition  to  the  flexibility  features  directed  towards 
accommodating  weapon  system  changes,  flexibility  is  desired  to 
accommodate  changes  in  the  simulator  instructional  features  and  in 
the  computational  system  Examples  of  such  features  include 

t.  The  use  of  shared  memory  as  an  intrastation 
communication  area  to  provide  extensive  expansion 
capability  within  each  station  Current  typical  shared 
memory  systems  can  support  up  to  16  processors 
providing  ample  system  expandability 

2  Synchronization  provided  by  a  single  master  clock  so  that 
any  number  of  additional  processors  can  be  added  to  a 
station  by  cabling  to  the  intrastation  synchronization 
interrupt 


3  Station-to-station  transfers  using  direct  memory  access  of 
shared  memory  areas  under  control  of  the  station 
executive  software  All  interstation  transfers  are 
accomplished  by  a  single  processor  in  each  station  The 
addition  of  processors  to  any  particular  station  will  not 
impact  the  interstation  transfers 

4  A  phased  mission  build  process  to  provide  mission 
generation  personnel  the  capability  of  linking  existing 
instructor  page  files  to  different  mission  profiles  Thus,  a 
new  mission  can  easily  be  created  for  a  new  geographical 
area  using  standardized  mission  events 

Summary 

In  summary,  we  find  that  planned  and  coordinated  generation  of  the 
required  weapon  system  design  criteria  data  concurrently  with  a 
simulator  program,  which  addresses  design  flexibility,  provides  the 
most  effective  approach  to  having  the  desired  trainer  capability  at  the 
desired  time 
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ABSTRACT 

This  paper  reports  the  status  of  an  ongoing  project  to  develop  a  macro 
model  describing  the  decisions  involved  in  developing  training  equipment.  The 
purpose  of  the  model  is  to  assist  managers  in  making  such  decisions  by  pro¬ 
viding  information  concerning  the  tradeoffs  between  the  cost  and  effectiveness 
of  training  provided  by  different  configurations  and  choices  of  equipment. 
The  goals  of  the  current  phase  of  the  study  were  to  determine  the  feasibility 
of  collecting  data  to  empirically  test  the  model  and  turn  it  into  a  practical 
tool  to  be  used  in  making  decisions  relating  to  trainer  design  and  develop¬ 
ment,  and  to  perform  a  preliminary  test  of  the  model. 

Results  of  the  field  data  collection  led  to  the  conclusion  that  the  data 
necessary  to  test  the  model  can  be  obtained.  However,  such  measures  need  to 
be  refined  before  the  model  can  be  turned  into  a  practical  tool.  The  prelim¬ 
inary  test  of  the  model  performed  in  this  study  resulted  in  no  major  modifica¬ 
tions  of  the  model. 


PURPOSE 

This  paper  reports  the  status  of  an 
ongoing  project  to  develop  a  practical 
model  to  assist  managers  in  making 
decisions  concerning  training  equipment. 
The  model  is  designed  to  permit 
comparisons  of  the  cost  and  effectiveness 
of  alternative  configurations  of  training 
equipment.  The  model  will  allow  managers 
to  make  cost/benefit  tradeoffs  between  the 
various  characteristics  that  may  be 
utilized  in  training  equipment,  and  give 
both  the  military  and  industry  guidelines 
to  justify  decisions  relating  to  trainer 
design. 

The  purpose  of  the  current  phase  of 
the  study  was  two-fold: 

(1)  To  determine  the  feasibility  of 
data  collection  for  empirical 
validation  of  the  model,  and 

(2)  To  perform  a  preliminary  test  of 
the  model. 

BACKGROUND 

In  their  1982  Summer  Study  on  Train¬ 
ing  and  Training  Technology,  the  Defense 
Science  Board  concluded  that  consideration 
must  be  given  to  training  effectiveness 
during  the  design  and  development  of  mili¬ 
tary  training  systems.  This  conclusion 
was  based  on  the  fact  that  effective 
training  is  essential  in  order  to  maintain 
operational  readiness  (1).  In  a  recent 
evaluation  of  operational  trainers,  the 


General  Accounting  Office  stated  that  most 
training  equipment  is  designed  without  due 
consideration  to  training  effectiveness 
(2).  It  is  essential,  therefore,  that 
tools  be  developed  so  that  the  effective¬ 
ness  of  training  equipment  can  be  esti¬ 
mated  during  the  design  and  development 
phases.  In  this  way,  knowledgeable  trade¬ 
offs  can  be  made  between  both  the  cost  and 
effectiveness  of  training  equipment  during 
the  development  process. 

The  Air  Force  Human  Resources 
Laboratroy  concluded  recently  that  no  such 
practical  model  exists  as  yet  (3) .  Such  a 
model  is  necessary  to  aid  both  the  Armed 
Services  and  industry  in  defining  the 
requirements  needed  to  design  training 
systems  that  training  personnel  adequately 
and  at  a  minimum  cost.  The  current  study 
is  part  of  an  ongoing  project  to  help  meet 
this  need. 


of  an 


Model 


A  preliminary  version  of  a  model  was 
described  last  year  (4).  All  terms,  such 
as  "effectiveness"  and  "cost"  were  defined 
operationally  for  measurement  both  at 
school  and  on  the  job;  cost  included 
acquisition,  operation,  and  support.  A 
taxonomy  was  provided  to  describe  the 
characteristics  of  a  training  device. 
Provisions  were  also  made  for  specifying 
relevant  characteristics  of  students, 
instructors,  and  training  goals.  A 
graphic  depiction  of  the  model  is  given  in 
Figure  1. 


TRAINING  PROGRAM  GOAL 


PRELIMINARY  TEST  OF  THE  MODEL 


The  purpose  of  this  test  was  to 
examine  the  feasibility  of  collecting  data 
needed  to  develop  and  use  the  model.  The 
problem  was  to  compare  the  effectiveness 
of  training  of  F-16  maintenance  techni¬ 
cians  when  either  simulators  or  actual 
equipment  had  been  used  in  training 
courses.  Data  were  collected  at  Hill  Air 
Force  Base,  Utah,  and  Hahn  Air  Base, 
Germany,  where  simulators  were  used  since 
August  1979  and  August  1981,  respectively; 
data  were  also  collected  at  Nellis  Air 
Force  Base,  Nevada,  where  simulators  had 
never  been  used. 

The  F-16  simulators  consist  of  six 
free-play  systems  designed  to  assist  in 
teaching  maintenance  courses  in  flight 
controls,  communication,  navigation,  and 
electrical  systems,  and  engine  start, 
engine  diagnostics  and  engine  run  for  the 
F-16  aircraft. 

Data  Collection  Instruments.  Two 
sets  of  data  collection  instruments  were 
used.  A  set  of  Behaviorally  Anchored 
Rating  Scales  (BARS)  was  developed  to 
assess  technicians'  performance  in  the 
field.  Instructors,  in  the  role  of 
subject  matter  experts,  were  asked  to 
create  a  series  of  critical  incidents 
describing  behaviors  which  differentiate 
between  a  good  technician  and  a  poor  one. 
The  incidents  focused  on  specific 
technician  actions  closely  related  to  the 
job,  and  differentiated  between  success 
and  failure  as  a  maintenance  technician. 
The  incidents  were  rated  by  the 
instructors  on  a  seven-point  scale  with 
the  scale  value  of  1  being  very  poor 
performance  behavior  and  the  scale  value 
of  7  being  very  high  performance  behavior. 
Those  incidents  with  the  lowest  standard 
deviations  and  means  closest  to  1  and  7 
were  then  placed  on  a  graphic  type  rating 
scale  to  be  used  as  behavioral  anchors  for 
the  scales. 

There  are  two  advantages  to  using 
BARS:  first  of  all,  the  description  of 

the  scale  points  is  written  in  terms  that 
can  be  easily  understood  by  the  raters. 
Second,  since  the  type  of  person  who 
developed  the  scale  is  also  the  type  of 
person  who  uses  the  scale,  the  raters  have 
a  vested  interest  in  using  the  scales 
correctly  (5) . 

The  use  of  the  BARS  development 
technique  in  this  study  yielded  seven 
specific  scales: 

(1)  Safety:  Behaviors  which  show 

that  the  technician  understands 
and  follows  safety  practices  as 
specified  in  the  technical  data; 

Detai Is:  Behaviors  which  show 

that  the  technician  is  well 


prepared  when  he  arrives  on  the 
job,  carries  out  maintenance 
procedures  completely  and 

thoroughly,  and  recognizes  and 
attends  to  symptoms  of  equipment 
damage  or  stress; 

(3)  LLS£  Ol  Technical  Data:  Be¬ 

haviors  which  show  that  the 
technician  properly  uses  tech¬ 
nical  data  in  the  performance  of 
maintenance  functions; 

(4)  System  Understanding:  Behaviors 

which  show  that  the  technician 
thoroughly  understands  system 
operation  allowing  him  to  recog¬ 
nize,  diagnose,  and  correct 
problems  not  specifically 

covered  in  the  technical  data 
and  publications; 

(5)  Understanding  of  Other 
Behaviors  which  show  that  the 
technician  understands  the 
systems  that  interconnect  with 
his  specific  system  and  can 
operate  them  in  accordance  with 
the  technical  data; 

(6)  Mechanical  Skil Is:  Behaviors 

which  show  that  the  technician 
possesses  specific  mechanical 
skills  required  for  even  the 
most  difficult  maintenance  prob¬ 
lems;  and 

(7)  Attitude :  Behaviors  which  show 

that  the  technician  is  concerned 
about  properly  completing  each 
task  efficiently  and  on  time. 

The  second  data  collection  instrument 
was  a  series  of  questionnaires  for  stu¬ 
dents,  instructors,  and  technicians. 
These  questionnaires  were  used  to  collect 
two  types  of  information:  (1)  demographic 
information  concerning  respondents'  back¬ 
ground,  training,  and  experience,  and  (2) 
subjective  information  such  as  respon¬ 
dents'  attitudes  toward  training  devices 
in  general,  and  their  perceptions  and 
evaluations  of  the  specific  device  with 
which  they  were  working. 

Data  on  training  effectiveness  were 
collected  through  student  course  test 
scores  and  Work  Unit  Code  (WUC)  informa¬ 
tion.  A  new  system  known  as  the  Consoli¬ 
dated  Data  System  (CDS)  has  been  insti¬ 
tuted  for  the  F-16  aircraft  that  allows 
for  more  flexible  and  responsive  mainte¬ 
nance  data  reporting  than  was  previously 
available.  This  system  relies  on  mainte¬ 
nance  information  recorded  by  each  work 
center  on  Air  Force  Form  AFTO  349, 
"Maintenance  Data  Collection  Record," 
which  is  entered  into  the  data  base  at 
each  wing.  The  advantage  of  using  the  CDS 
is  the  ability  to  aggregate  maintenance 
data  in  a  more  usable  form  and  with  flex¬ 
ibility  as  to  which  information  is  dis¬ 
played.  The  information  needed  for  the 
current  study  was  which  component  was 


worked  on  (WUC) ,  what  action  was  taken, 
the  time  necessary  to  complete  the  action, 
and  what  work  center  performed  the  action. 

The  purpose  was  to  determine  whether 
maintenance  data  records,  collected  rou¬ 
tinely,  might  provide  data  on  the  effec- 
tivness  of  maintenance  training.  In  this 
case  the  issue  was  to  see  if  technicians 
trained  with  simulators  performed  differ¬ 
ently  from  technicians  not  trained  with 
simulators . 

Procedure .  Data  were  collected  using 
the  three  versions  of  the  questionnaire 
(student,  instructor,  technician)  to 
gather  background  data  concerning  the 
subjects  and  their  opinions  of  training 
courses  and  devices.  The  BARS  were  used  to 
determine  the  instructors'  and  supervi¬ 
sor's  performance  appraisals  of  those 
students  having  previously  graduated  the 
courses.  This  repeated  use  of  the  BARS 
was  intended  to  help  determine  the  valid¬ 
ity  of  such  subjective  judgments,  and  to 
partially  ascertain  the  relationship  be¬ 
tween  judgments  of  technician  performance 
at  the  school  and  the  field  levels.  The 
distributions  of  subjects  receiving  these 
instruments  are  given  in  Tables  1  and  2. 

Table  1.  Breakdown  of  Questionnaire 
Respondents  by  Base  and 
Status 


Hill 

Hahn 

Nellis 

Instructors 

8 

15 

10 

FTD  Students 

26 

13 

19 

Technicians 

38 

15 

8 

Table  2.  Breakdown  of  Performance 
Assessments  by  Base  and 
Status 


Hill 

Hahn 

Nellis 

Current  FTD 
Students 

17 

7 

19 

Current 

Technicians 

44 

13 

10 

Past  FTD 
Students 

0 

11 

37 

The  procedure  for  determining  the 
maintenance  productivity  of  specific  work 
centers  started  with  the  choice  of  the 
specific  work  unit  codes  to  be  examined. 
Although  there  are  six  F-16  trainers  which 
are  of  interest  in  this  study,  due  to  the 
small  number  of  observations  associated 
with  the  uc.ion  codes  included  in  several 
of  the  WUC's,  it  was  not  possible  to 
gather  sufficient  data  to  analyze  all  six 


of  these  trainers.  Two  system-level  WUC's 
were  found  to  have  a  sufficient  number  of 
action  code  observations  to  be  included. 
These  were  14000,  Flight  Control  Systems, 
which  is  applicable  to  courses  in  flight 
controls  and  instrumentation,  and  23000, 
Turbofan  Power  Plant,  which  is  applicable 
to  courses  in  engine  diagnostics.  Within 
these  system-level  WUC's,  two  component- 
level  WUC's  were  chosen  for  further 
analysis:  14A00,  Primary  Flight  Control 
Electronics,  and  23Z00,  Turbofan  Power 
Plant  (F-100  engine).  These  WUC's  were 
chosen  for  analysis  because  they  were 
directly  related  to  actions  taught  on  the 
maintenance  trainers  and  the  number  of 
observations  was  sufficient  for  analysis. 


Correlations  between  BARS  ratings 
made  by  supervisors  of  technician's  per¬ 
formance  in  the  field  and  the  ratings  made 
by  instructors  of  the  same  technician's 
performance  in  the  school  setting  are 
shown  in  Table  3.  The  correlations  are 
low,  indicating  that  the  success  of  a 
technician  as  measured  by  the  BARS  cannot 
be  predicted  from  his  performance  in  the 
training  course.  The  only  performance 
measure  that  shows  a  statistically  signi¬ 
ficant  relationship  between  school  and 
field  performance  is  the  scale  measuring 
"Use  of  Technical  Data"  (t  =  .5).  This 
correlation  indicates  only  a  moderate 
relationship,  with  25%  (£.2 )  of  the  var¬ 
iance  of  the  technicians'  scores  accounted 
for  by  their  student  scores.  These  re¬ 
sults  suggest  that  such  ratings  of  student 
performance  in  school  settings  do  not 
provide  a  valid  predictor  of  performance 
in  the  field. 

A  repeated  measures  analysis  of  vari¬ 
ance  (ANOVA)  on  the  BARS  data  suggested 
that  there  is  an  improvement  in  perfor¬ 
mance  over  time  for  both  types  of  training 
(i.e.,  trainer  or  actual  equipment)  after 
the  students  graduate  and  perform  mainte¬ 
nance  procedures  in  the  field.  The  one 
exception  to  this  is  the  "Understanding  of 
Other  Systems"  scale  (see  Table  4). 
Ratings  given  to  the  technicians  who  were 
trained  using  the  actual  equipment  appear 
to  be  consistently  higher  than  for  those 
trained  using  the  trainers  (Figure  2). 
The  ratings  for  technicians  trained  by  the 
two  methods,  however  (once  again  with  the 
exception  of  the  scale  "Understanding  of 
Other  Systems"),  appear  to  converge  over 
time.  The  average  length  of  time  between 
course  graduation  and  supervisor  perfor¬ 
mance  rating  was  three  and  a  half  months. 
This  suggests  that  improvement  in  perfor¬ 
mance  produced  by  different  training 
methods  dissipates  as  on-the-job  training 
increases.  The  goal  of  devising  a  more 
effective  training  system,  therefore, 
actually  becomes  one  of  producing  compe¬ 
tent  technicians  faster  than  by  other 
methods . 
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Table  3.  Correlations  Between  Performance  Ratings  (BARS)  of 
Course  Graduates  as  Students  and  as  Technicians 


Performance  Measure 

Pea  i  son  i_ 

Safety 

0.221 

Thoroughness 

0.169 

Use  of  Technical  Data 

0.526* 

System  Understanding 

0.381 

Understanding  of  Other  Systems 

0.111 

Mechanical  Skills 

0.156 

Atti tude 

0.328 

*P  i  .05 
M  =  18 


Table  4.  F  Values  for  BARS  Score  Improvement  Over 
Time  (Repeated  Measures  ANOVA) 

Scale  £  Value  p 


Safety 

Thoroughness 

Use  of  Technical  Data 

System  Understanding 

Understanding  of  Other  Systems 

Mechanical  Skills 

Attitude 


Although  the  differences  between 
ratings  of  course  graduates  as  students 
and  as  technicians  are  not  all 
statistically  significant  at  the^>  =  .05 
level,  the  trends  are  clear.  Statistical 
significance  is  difficult  to  achieve  with 
small  samples,  even  though  an  underlying 
trend  may  indeed  exist.  It  is  important, 
also,  to  note  that  the  average  performance 
rating  for  both  groups  is  above  the  4.0 
midpoint  (halfway  between  the  1.0  minimum 
and  the  7.0  maximum  performance  ratings) 
for  each  of  the  seven  measures.  This  may 
be  interpreted  to  mean  that  both  types  of 
training  are  producing  at  least 
satisfactory  technician  performance. 

In  the  analysis  of  the  WUC's  data  for 
WUC  14A00  it  was  found  that  the  greater 
the  degree  of  worker  training,  the  better 
the  productivity  of  the  unit  (ree  Figure 
3).  This  was  true  for  17  out  of  the  18 
data  points.  Only  the  remove  after  canni¬ 
balization  action  showed  a  slight  reversal 
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of  this  pattern.  For  WUC  23Z00,  the  same 
trend  was  found.  In  this  comparison, 
training  appears  to  bear  some  relationship 
to  productivity  (see  Figure  4).  The  two 
highest  trained  at  74  percent,  were  both 
more  productive  for  each  action  code  than 
the  least  trained  base,  at  59  percent. 


The  first  goal  of  the  current  study 
was  to  determine  the  feasibility  of 
collecting  practical  data  for  use  in  vali¬ 
dation  of  the  model.  The  work  unit  code 
data  show  promise  for  being  valid  on-the- 
job  measures  of  training  effectiveness. 
This  can  be  seen  in  the  comparisons  of 
performance  of  technicians  trained  in  FTD 
courses  versus  those  who  had  not  received 
such  formal  training.  However,  the  WUC's 
data  as  used  in  the  current  study  need 
refinement  for  use  as  a  measure  of  train¬ 
ing  effectiveness. 
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Figure  2.  Cell  Means  for  BAKS  Repeated  Measures  ANOVA  Between  Course 
Graduates  as  Students  and  as  Technicians 
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Figure  3.  Training:  Wing-to-Wing  (14A00) 


Some  problems  inherent  to  the  Air 
Force  maintenance  data  collection  system 
may  limit  its  accuracy  as  a  measure  of 
performance  relevant  to  training.  For 
example,  problems  with  data  recording  and 
data  entry  could  lead  to  biases  or 
inaccurate  data  analyses.  Second,  while 
WUC's  that  are  associated  with  actions 
taught  using  maintenance  simulators  can  be 
identified,  these  WUC's  tend  to  be  very 
specific.  In  the  refinement  of  the  WUC|s 
data  as  measures  of  field  performance  it 
will,  therefore,  be  necessary  to  take  this 
fact  into  consideration  in  order  to 
develop  the  most  useful  measure  of 
training  effectiveness  possible.  Firally, 
in  the  interpretation  of  any  data  based 
upon  WUC's  information,  one  must  also 
consider  the  environmental  influences  on 
maintenance  technicians  which  occur  in  the 
field  and  which  may  lead  to  differences  in 


performance  between  bases  that  are  not  due 
to  training  (6) . 

The  second  goal  of  the  current  study 
was  to  perform  a  preliminary  test  of  the 
training  effectiveness  model.  The  BARS 
data  (i.e,,  rating  scales)  suggested  dif¬ 
ferences  in  th  performance  on  the  job 
between  students  trained  on  simulators  or 
actual  equipment.  These  differences 
lessen  as  on-the-job  training  increases. 
However,  only  ratings  on  one  measure  ("Use 
of  Technical  Data")  at  school  are  corre¬ 
lated  significantly  with  the  same  measure 
on  the  job.  Several  questions  need  to  be 
answered.  First,  do  the  technicians 
trained  with  the  trainers  eventually  per¬ 
form  as  satisfactorily  as  those  trained 
with  the  actual  equipment?  Second,  is  the 
additional  on-the-job  training  necessary 
to  bring  a  trainer-taught  technician  up  to 
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Figure  4.  Training: 

a  satisfactory  performance  level  equiva¬ 
lent  to  that  of  actual  equipment-trained 
technicians  worth  the  cost?  The  answer  to 
these  questions  can  only  come  from  a  long¬ 
itudinal  study  that  controls  for  confound¬ 
ing  variables.  Particular  care  must  be 
taken  to  control  for  the  length  of  time 
subjects  have  spent  in  aircraft  mainte¬ 
nance,  since  this  is  likely  to  have  a 
strong  effect  on  performance.  Those 
trained  on  the  actual  equipment  should  be 
compared  to  those  trained  on  the  individ¬ 
ual  trainers  as  the  data  indicate  the 
possibility  that  some  trainers  may  be 
doing  a  better  job  of  preparing  techni¬ 
cians  than  other  trainers. 

FUTURE  DIRECTIONS 

Several  steps  need  to  be  taken  to 
develop  a  model  that  can  be  used  to  make 
decisions  regarding  tradeoffs  between  cost 
and  training  effectiveness.  First,  a  more 
rigorous  validation  of  the  training  effec¬ 
tiveness  model  must  be  made.  The  model 
should  be  tested  with  real  world  data  and 
be  modified  as  required.  Second,  an  over¬ 
lay  for  the  training  effectiveness  model 
must  be  developed  which  relates  the  var¬ 
ious  design  parameters  to  their  costs. 
Finally,  these  two  sections  must  be  syn- 
thesired  so  that  tradeoff  equations 


Wing-to-Wing  (23Z00) 

between  cost  and  training  effectiveness 
can  be  developed,  and  the  model  turned 
into  a  practical  tool.  The  outline  of 
these  steps  is  given  in  Figure  5. 

It  will  also  be  necessary  to  quantify 
the  design  parameters  used  in  the  model  so 
that  they  can  be  meaningfully  related  to 
the  other  variables  of  the  model.  This 
requires  several  steps.  First,  quantita¬ 
tive  scales  must  be  developed  for  the 
dimensions  of  realism  and  of  instructional 
aids  used  in  the  model.  This  can  be 
accomplished  through  the  use  of  scaling 
methods,  such  as  the  Coombs  Unfolding 
Technique,  which  determine  the  intervals 
between  various  points  on  a  qualitative 
scale,  as  in  the  current  model.  Concom¬ 
itantly,  it  will  also  be  necessary  to 
refine  the  effectiveness  measures  (  i.e., 
field  performance)  so  that  they  are  as 
meaningful  as  possible.  When  these  two 
steps  are  accomplished  it  will  then  be 
possible  to  collect  field  data  on  a  repre¬ 
sentative  sample  of  training  equipment  to 
determine  their  configuration  in  terms  of 
extent  and  degree  of  realism  and  instruc¬ 
tional  aids,  and  their  resulting  effec¬ 
tiveness  for  a  given  training  goal.  These 
data  can  then  be  used  to  validate  and/or 
refine  the  model. 
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The  second  step  in  developing  the 
working  model  into  a  practical  tool  is  to 
develop  a  cost  overlay.  This  requires  not 
only  data  on  the  costs  of  alternative 
components  in  a  trainer,  but  also  data  on 
the  cost  of  additional  on-the-job  training 
necessary  for  a  course  graduate  to  attain 
minimum  proficiency  in  the  field.  When 
this  has  been  accomplished  it  will  then  be 
possible  to  develop  working  equations 
which  allow  tradeoffs  between  cost  and 
training  effectiveness  to  be  made  during 
the  design  and  development  of  a  training 
device . 
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COST-EFFECTIVE  AND  EFFICIENT  MAINTENANCE  TRAINING  DEVICES: 
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In  response  to  a  USAF  need  for  cost-effective  and  efficient  training  devices  for  the  F-16 
aircraft,  a  design  process  which  was  largely  adapted  from  U.S.  Air  Force  instructional  design 
procedures  was  used  and  modified  to  ensure  the  efficient  integration  of  these  devices  within  the 
USAF  training  and  logistics  environments.  Two  specific  and  unique  training  device  suites  were 
conceptualized  for  the  F-16  Fire  Control  and  Armament  systems.  Physical  and  functional 
characteristics  were  specified  for  each  training  device  suite  to  meet  the  specific  hands-on 
training  needs  for  Fire  Control  (AFSC  326X6C)  and  Weapons  Control  (AFSC  462X0)  maintenance 
technicians . 


BACKGROUND 


Requirement 


The  F-16  System  Program  Office  at 
Wr ight-Pa tterson  AFB,  Ohio,  required  the 
conduct  of  an  analysis  to  determine  the 
optimum  maintenance  training  device(s)  to 
support  USAF  organizational  maintenance 
training  for  two  Air  Force  Speciality  Codes 
(AFSCs).  These  two  AFSCs  are  the  Integrated 
Avionics  Specialist  (AFSC  326X6C)  and  the 
Weapons  Maintenance  Technician  (AFSC  462X0), 
each  respectively  working  on  the  Fire  Control 
System  and  the  Armament  Systems  of  the  F-16 
aircraft.  An  original  study  conducted  in  1977 
had  indicated"  the  need  for  the  development  of 
maintenance  simulators  for  the  support  of 
maintenance  training  for  the  F-16  Fire  Control 
and  Armament  Systems,  however,  a  reevaluation 
of  the  original  concept  to  determine  the 
optimum  media  was  required. 

Constraints 

Two  primary  factors  of  concern  associated 
with  the  development  of  these  training  devices 
were  cost-effectiveness  and  the  ability  to 
accommodate  changes  in  hardware  and  software 
as  a  result  of  F-16  aircraft  Engineering 
Change  Proposal  (ECP)  or  Technical  Order 
procedures  modification.  Cost-effectiveness 
entailed  maximizing  training  effectiveness, 
i.e.,  the  accomplishment,  proficiency  and 
maintenance  of  desired  training  objectives, 
while  minimizing  development  and  life  cycle 
costs.  Inherent  within  the  ability  to  update 
hardware  and  software  on  the  training  device 
is  the  timeliness  associated  with  making  the 
required  changes  in  order  to  provide  a 
training  environment  consistent  with  the 
operational  environment. 

Learning  Environment 

The  training  devices  were  to  be  designed 
to  support  organizational  maintenance  training 
at  the  Field  Training  Detachments  (FTD)  and 
similar  training  environments.  The  target 
population  Included  students  having  graduated 
from  Air  Force  Technical  Training  Centers,  and 
students  who  were  cross  training  from 
different  aircraft  communities.  Following 
training  at  the  FTDs,  students  would  then  be 


assigned  to  the  operational  environment. 
Training  device  design  therefore  had  to 
account  for  the  integration  of  the  device(s) 
into  the  curriculum  to  ensure  that  it  both 
supports  the  curriculum  and  provides  the 
required  reinforcement  for  training  of  skills 
and  procedures. 


Available  Air  Force  procedures  using  the 
Instructional  System  Development  (ISD)  process 
for  the  systematic  identification  of  skills 
and  knowledge  to  be  taught  in  order  to  ensure 
successful  training,  included  the  Air  Force 
Pamphlet,  Handbook  for  Designers  of 
Instructional  Systems,  (AFP  50-38),  the  3306th 
Test  and  Evaluation  Squadron,  Procedural 
Handbook  and  the  Air  Force  Human  Resources 
Laboratory,  Maintenance  Training  Simulator 
Design  and  Acquisition  -  Handbook  of  ISD 
Procedures  for  Design  and  Documentation. 

These  procedures  were  reviewed  in  order  to 
determine  their  applicability  to  the 
objectives  of  this  study.  The  AFP  50-58  and 
the  3306th  Procedural  Handbook  did  not 
adequately  address  the  details  in 
determination  of  a  requirement  for  training 
devices  nor  the  selection  of  required  training 
devices.  On  the  other  hand,  the  AFHRL 
Handbook,  originally  developed  to  supplement 
the  procedures  in  the  aforementioned 
documents,  provided  a  detailed  and 
comprehensive  process  for  training  equipment 
design.  This  latter  process,  although  adopted 
from  the  start,  was  determined  to  be  too 
lengthy  and  incorporated  unnecessary  steps  for 
the  purpose  of  this  study.  For  example,  with 
respect  to  component  fidelity,  the  AFHRL 
Handbook  provides  an  extremely  detailed  and 
labor  intensive  procedure  for  determining 
levels  of  fidelity  defined  as  High  (H),  Medium 
(M)  or  Low  (L)  for  each  component.  This 
information  was  then  consolidated  by  task  and 
groups  of  tasks  prior  to  eventually  describing 
the  simulated  components  in  detail.  In  the 
procedure  used  for  the  F-16  systems  a 
description  of  the  physical  and  functional 
characteristics  for  each  component  was 
immediately  derived  from  those  skills  and 
knowledge  that  were  determined  to  require  a 
training  device.  The  difference  between  the 
two  processes  is  as  follows.  In  the  first 
instance,  a  significant  amount  of  time  was 
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devoted  to  defining  the  level  of  fidelity  (H, 

M  or  L)  for  each  component.  In  the  second 
instance  the  levels  of  fidelity  were 
immediately  established  by  describing  what  the 
components  must  "look*’  and  “feel"  like  and 
what  stimulus  and/or  equipment  feedback  were 
necessary  for  the  performance  of  each  hands-on 
task.  The  streamlined  procedure  in  this 
latter  case  was  a  timesaver  for  the  purpose  of 
this  study. 

In  addition,  the  AFHRL  Handbook  did  not 
describe  a  process  for  identification  of 
applicable  alternatives  and  selection  of  a 
final  design  for  training  systems.  There  are 
two  advantages  in  using  such  a  selection 
process.  First,  the  hardware  and  software 
concepts  will  be  defined  for  the  training 
device  manufacturer;  second,  they  will  have 
been  defined  by  the  same  team  that  performed 
the  front-end  analysis.  On  one  hand,  a  more 
definitive  specification  is  handed  the 
manufacturer;  on  the  other,  no  learning  curve 
will  have  to  be  established  for  the  team 
performing  the  trade-off  analyses  and  final 
selection. 

Using  the  aforementioned  USAF  documents  as 
a  study  reference,  a  streamlined  approach  was 
designed  and  implemented,  and  the  principle 
elements  of  this  approach  are  described  in 
this  paper. 

ANALYSIS 

Data  Collection 

Initial  data  included  information 
contained  in  appropriate  USAF  Technical  Orders 
(TOs)  for  the  F-16  aircraft.  These  included 
General  Vehicle,  Fault  Isolation  and  system 
specific  manuals  from  which  an  understanding 
of  the  operational  system,  and  a  preliminary 
assessment  of  the  scope  of  work  was  made. 

More  detailed  documents,  such  as  engineering 
drawings,  were  required  further  along  in  the 
analysis  process.  TOs  also  included  the 
applicable  Job  Guides  for  the  Fire  Control  and 
i\  aament  Systems  which  provided  the 
step-by-step  procedures  the  technician  would 
perform  for  a  given  maintenance  action. 

A  prime  source  of  relevant  data  were  the 
training  activities  at  FTD  and  at  TAC 
(Tactical  Air  Command,  the  operational 
squadrons).  One  reason  for  this  source 
selection  is  that  user  dissatisfaction  with 
training  programs  can  be  the  result  of  several 
factors  such  as  course  design  or  instructor 
preparation.  Therefore,  it  is  important  to 
Interview  instructors  and  maintenance 
technicians  to  identify  specific  problems  and 
desired  features  for  the  training  devices. 

Additionally,  existing  data  related  to  the 
performance  of  F-16  systems  such  as  field 
performance  reports  and  frequency  of  repair 
records  were  also  reviewed.  De.ta  contained  In 
those  items  were  useful  in  developing  a 
comprehensive  listing  of  malfunctions  which 
were  an  lay zed  for  training  requirements. 


Task  Analysis 

Preliminary  Task  Listing.  Initial  task 
listings  were  generated  using  the  USAF 
Technical  Order  System.  Those  TOs  that 
applied  to  any  and  all  work  performed  by  AFSCs 
326X6C  and  462X0  at  the  organizational  level 
and  on  the  particular  block  aircraft 
configuration  (Block  10),  were  used  for 
initial  task  identification.  Additional 
sources  of  information  were  used  during  the 
validation  of  the  initial  task  listing  to 
include  USAF  Subject  Matter  Experts  (SMEs)  and 
General  Dynamic's  field  representatives  and 
in-plant  engineers. 

Valid  task  descriptions  represent  the 
basic  data  source  upon  which  the  entire 
front-end  analysis  rests.  In  order  to  ensure 
the  technical  accuracy  and  completeness  of  the 
data  gathered,  tasks  derived  from  the 
technical  documentation  were  verified  by 
E-Tech  ISD  personnel  with(l)  TAC  F-16 
Aircraft  Generation  Squadron  maintenance 
supervisors  and  technicians  and  (2)  ATC  Field 
Training  Detachment  SMEs. 

Validation.  A  two  step  process  was  used 
to  verify  the  initial  task  listing.  First, 
each  task  for  each  subsystem  of  the  Fire 
Control  System  and  the  Armament  System  was 
reviewed  and  verified  by  SMEs  for  technical 
accuracy  and  completeness,  down  to  subsystem 
components  and  lowest  replaceable  units. 
Second,  all  subtasks,  elements  steps  and 
procedures  associated  with  each  task  were 
reviewed  and  verified  by  SMEs  for  completeness 
and  accuracy.  Subtasks  and  task  element 
additions,  modifications,  or  deletions 
discovered  during  reviews  were  recorded. 

Sites  visited  for  the  validation  process 
Included  MacDill  AFB,  Tampa,  Florida,  and  Hill 
AFB,  Odgen,  Utah. 

The  validated  task  listing  was  then  used 
to  group  common  tasks  which  were  classified 
into  one  of  the  following  four  categories: 

•  Operational  Check-Out  Procedures 

•  Fault  Isolation  Techniques 

•  Corrective  Actions 

•  General  Maintenance 

Tasks  to  be  Trained.  With  the  help  and 
guidance  of  FTD  Instructors,  the  validated 
task  listing  was  compared  with  the  prospective 
student  entry  level  skills  at  course  entry 
and,  based  on  FTD  curriculum  requirements  as 
described  and  defined  by  USAF  Plans  of 
Instruction  (POIs),  Course  Training  Standards 
(CTSs)  and  Specialy  Training  Standards  (STSs), 
a  listing  of  tasks  to  be  trained  was 
developed.  Normally  at  this  point,  the  tasks 
to  be  trained  would  have  been  categorized  iito 
three  groupings.  The  first  grouping  would  iC 
those  tasks  requiring  classroom  training  for 
knowledge  and  introduction  to  systems, 
procedures  and  maintenance  activity.  The 
second  grouping  would  be  those  tasks  requiring 
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hands-on  reinforcement  or  practice  with  the 
aid  of  a  training  device.  The  third  grouping 
would  include  those  tasks  requiring  an 
on-the-job  training  (OJT)  environment  to  be 
learned.  This  study  focused  only  on  the 
second  grouping,  the  hands-on  tasks  to  be 
trained . 

Hands-On  Tasks  to  be  Trained.  Each  step 
and  activity  associated  with  each  task  to  be 
trained  was  further  analyzed.  This  analysis 
yielded  a  set  of  behavioral  requirements 
(skills/knowledge)  for  the  performance  of  each 
step.  Those  skills  and  knowledge  that  were 
determined  to  have  a  training  requirement  were 
then  compared  to  established  criteria  to 
determine  which  required  the  support  of 
training  equipment.  Criteria  included: 

•  Difficulty  of  execution 

•  Unique  environmental  conditions 
requiring  special  training 

•  Timing  or  error  criteria 

•  Special  use  of  test  equipment 

•  Personnel  and  equipment  safety 

•  Frequency  of  performance 

Only  those  skills  selected  for  hands-on 
training  formed  the  basis  for  the  description 
of  specific  component  characteristics  to  be 
represented  on  the  training  device. 

Component  Characteristics.  The  components 
identified  as  a  result  of  the  selection  of 
skills  requiring  hands-on  training  would  be 
those  components,  which  when  put  together  in 
some  combination,  would  comprise  the  sought 
after  training  device.  The  level  of  fidelity 
of  each  component  was  determined  by  describing 
only  the  required  physical  and  functional 
characteristics  necessary  for  the  performance 
of  each  hands-on  skill.  The  grouping  of  these 
components  which  was  to  yield  desired  training 
device  alternatives  was  dependent  upon 
identifying  the  hands-on  training  requirements 
for  each  category  of  tasks. 

Hands-On  Training  (HOT)  Requirements. 
Further  analysis  revealed  that  each  category 
of  tasks  previously  classified  had  its  own  set 
of  hands-on  training  requirements.  For 
example,  the  hands-on  training  requirements 
for  the  Operational  Check  Out  Procedures 
emphasized  sequencing  of  activities  and 
responding  to  feedback  from  equipment. 
Specifically,  in  order  to  perform  an 
operational  checkout,  the  technician/ trainee 
had  to  be  able  to: 


1.  Manipulate  specific  controls  or  given 
components  in  a  sequential  order, 

2.  Respond  to  hardware  cues  which  are 
part  of  the  sequence,  and 

3.  Observe  the  displays  as  required  to 
complete  the  procedure. 

This  type  of  student-equipment  interaction 
description  was  developed  for  each  category  of 


tasks  and  formed  the  basis  for  describing  the 
configuration  of  applicable  training  devices. 

Training  Device  Physical  and  Functional 
Character! st ics.  The  physical  and  functional 
characteristics  for  each  possible  training 
device  alternative  were  based  on  the 
aforementioned  component  characteristics  and 
hands-on  training  requirements  for  each 
category  of  tasks.  For  each  system,  fire 
control  and  armament  control,  physical 
characteristics  described  what  each  component 
should  look  like,  how  it  should  function 
mechanically,  and  what  is  to  be  observed  from 
the  result  of  the  hands-on  manipulation. 
Functional  characteristics  described  the 
interface  requirements  for  the  components  and 
subsystems  to  meet  hands-on  training 
requirements.  These  characteristics  were 
documented  in  detail  and  were  to  be  used  in 
the  development  of  prime  item  specifications 
for  each  training  device  suite. 

SELECTION 

The  result  of  the  analysis  process  was  a 
description  of  the  training  device 
characteristics  necessary  to  meet  HOT 
requirements  for  the  F-16  Fire  Control  and 
Armament  Systems.  The  training  device 
characteri st ics  were  those  physical  and 
functional  features  of  a  training  device  tiiat 
described  the  size,  shape,  and  general 
appearance  of  the  device,  together  with  the 
visual,  aural  or  other  sensory  information  it 
must  provide. 

Selection  Criteria 

A  selection  process  was  designed  to  choose 
training  hardware  which  would  meet  the 
training  device  characteristics.  The 
selection  process  was  comprised  of  several 
steps: 

•  Establishment  of  selection  criteria 

•  Identification  of  training  hardware 
options 

•  Identification  of  viable  software 
options 

•  Selection  of  options  to  meet 
requirements  of  each  task  group 

•  Trade-off  analysis  on  the  options 

•  Selection  of  a  Final  Approach  co  the 
training  hardware  problem 

To  select  hardware  from  the  identified 
alternatives,  criteria  were  established  which 
would  provide  a  basis  for  that  selection.  The 
criteria  were: 

•  Component  Fidelity 

•  Update  Capability 

•  Reliability  of  Trainer 

•  Maintainability  of  the 
hardware/sof  tware 

•  Cost  of  hardware/software 

Component  Fidelity.  There  are  two  areas 
of  fidelity  considered  in  this  criteria. 
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First,  physical  tidelity  is  a  measure  of  how 
much  the  trainer  wiLi  look  like  the  actual 
equipment.  This  was  important  for 
remove/ replace  activities  or  operational  check 
procedures  because  the  entry  level  skills  of 
prospective  students  were  low  and  they  were 
relatively  unfamiliar  with  the  aircraft. 
Secondly,  functional  fidelity  indicates  how 
much  the  trainer  acts  like  the  real 
equipment.  This  refers  to  displays,  sounds, 
movements,  etc.  Functional  fidelity  is 
important  when  the  trainee  must  be  presented 
indications  which  provide  cues  or  feedback  to 
his/her  responses.  This  was  of  particular 
importance  to  the  F-16  fault  isolation 
training  requirements,  because  voltage  and 
current  readings  must  reflect  the  faults 
selected,  and  respond  to  the  trainee’s  fault 
isolation  activity. 

Rel iabi li ty ■  When  a  training  device  is 
relatively  free  from  frequent  failure  in  the 
training  environment,  It  is  considered  to  be 
reliable.  For  purposes  of  this  analysis, 
staff  engineers  and  subject  matter  experts 
evaluated  each  option  for  reliability  based  on 
past  history  of  candidate  systems. 

Maintainability.  Maintainability  refers 
to  expense  due  to  periodic  parts  replacement 
and  use  of  consumable  supplies,  and  to 
requirements  for  adjustmenets  and  calibration 
of  system  components.  Maintainability  was 
evaluated  in  the  same  manner  as  reliablity. 

Update  Capability.  Update  capability 
refers  to  the  ease  with  which  training  device 
hardware  and  software  can  be  updated  or 
changed  to  reflect  changes  in  the  parent 
weapon  system.  Since  the  F-16  is  an  ever 
evolving  system,  training  devices  must  be 
designed  to  accommodate  changes  in  the 
aircraft  system,  which  have  an  impact  on  the 
hands-on  training  requirements. 

Cost .  Cost  of  training  devices,  although 
not  necessarily  related  to  the  training 
capability  of  the  device,  must  of  course  be  a 
selection  criteria.  The  cost  of  all  systems 
was  compared  for  both  hardware  and  software 
requirements. 

F-16  Trainers 

In  the  case  of  the  F-16  trainers,  a  wide 
range  of  training  devices  was  considered  from 
actual  F-16  aircraft  to  low  fidelity 
trainers.  Guidelines  were  based  on  the  need*; 
of  training  device  characteristics  and  the  HOT 
requirements.  An  expert  panel  of  SMEs  and 
engineers  was  formed  to  select  training 
hardware.  F-16  aircraft  have  severe 
limitations  as  training  devices,  since  faults 
cannot  be  programmed  because  aircraft  cannot 
be  put  in  a  "down"  status.  Squadron 
commanders  frown  on  this.  Actual  equipment 
was  eliminated  as  a  training  hardware 
alternative.  Alternatives  which  were 
identified  as  viable  for  training  device 
designs  included: 


Aircraft  Peculiar  Trainers  (APTs)  - 
designed  to  look  and  act  like  a  portion  of  the 
aircraft,  e.g.,  the  cockpit. 

20/ 3D  Panels  -  panels  which  contain  3D 
replications  of  aircraft  components  and  2D 
resp resentat  i  ons  of  others,  and  in  total 
represent  a  complete  portion  of  an  aircraft. 

Computer  Assisted  Instruction  (CAT)  -  i n 
the  case  of  the  F-16,  this  was  defined  as 
interactive  video  trainers. 

Corrective  Action  Trainers  (CATs)  - 
training  hardware  which  is  a  physical  mock-up 
of  the  applicable  portions  of  the  aircraft, 
but  is  not  a  functional  representation. 

Software.  Software  designs  are  almost 
endless  in  variety.  The  designs  considered 
were  chosen  by  staff  engineers  and  were 
validated  by  client  engineers  as  feasible. 
Those  options  in  software  design  chosen  were: 

9  Operational  Software  -  designed  for 
aircraft  operation,  but  adapted  to  meet 
required  training  device  characteristics. 

•  Table  Driven  Software  -  based  on 
Technical  Order  procedures  and  is  total 
replication  of  the  Technical  Order  procedures. 

•  System  Modeled  Software  -  a 
mathematical  model  of  the  operational 
characteristics  of  each  actual  equipment 
component  represented  on  the  trainer. 

There  are  advantages  and  disadvantages  to 
each  option.  Basically,  the  most  flexible  and 
easiest  to  update  is  the  System  modeled 
software,  because  components  are  modeled 
individually  and  the  software  program  can  he 
done  in  modules.  The  least  expensive  to 
produce  is  the  table  driven.  Operational 
software  may  be  the  best  choice  where  actual 
equipment  makes  up  a  major  portion  of  the 
trainer. 

Expert  Panel.  Selection  of  training 
hardware  and  software  was  done  by  the  project 
team  in  conjunction  with  a  panel  made  up  of 
USAF  subject  matter  experts  and  training 
directors,  and  General  Dynamics  F-1G 
engineers.  Training  device  options  were 
identified  with  the  help  of  an  automated 
company  produced  survey  technique,  and 
presented  as  possible  approaches  to  the 
problem . 

Panel  Selection  Process.  A  preliminary 
selection  of  training  device  hardware  and 
software  was  presented  to  the  panel.  The 
panel  was  asked  to  validate  the  required 
training  device  characteristics,  in  view  of 
the  training  requirements.  Two  significant 
points  were  soon  made  by  the  panel,  whK'  had 
major  inpact  on  device  design.  These  points 
we  re : 


•  Instructional  features  are  costly 
characterist ics  on  a  training  device  which  the 
USAF  wanted  to  avoid  if  possible. 

•  Software  was  not  desired  which 
replicated  technial  manual  procedures  with 
minimum  flexibility  for  deviation,  or  which 
did  not  react  similar  to  the  actual  equipment. 

Instructional  features  were  defined  as 
those  components  of  a  training  device  which 
were  not  used  to  affect  the  operation  of  the 
trainer  as  a  replication  of  an  aircraft 
system,  but  which  assist  the  instructor  in 
controlling  the  learning  environment. 

Examples  of  instructional  features  are  devices 
which  record  scores  or  with  which  faults  can 
be  inserted.  Since  class  sizes  are  expected 
to  be  small,  no  instructional  features  were 
required  for  monitoring  or  recording  student 
activities.  Fault  insertion  was  required 
because  lessons  and  student  scenarios  are 
designed  around  faults  to  be  trained. 

Software  selection  was  dependent  on  the 
training  hardware  selected  and  the  task 
category  to  be  trained. 

Figure  1  depicts  the  hardware  options 
chosen  by  task  group. 
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Figure  2.  Training  Device  Suite 
Fire  Control  System. 

•  Aircraft  Peculiar  Trainer 


The  Aircraft  Peculiar  Trainer  (APT)  for 
the  Fire  Control  System  (FCS)  consists  of 
those  components  whose  physical  and  functional 
fidelity  are  required  to  meet  the  HOT 
requirements  arranged  in  the  configuration  of 
a  cockpit.  See  Figure  3  for  a  pictorial 
representation. 


Figure  1.  Alternate  Training  Devices 
Formed  by  Combinations  of  Training  Hardware 
Types  for  Each  Category. 

The  final  configuration  and  rationale  for 
selection  of  those  configurations  are 
discussed  in  the  following  section. 


Hardware  Selection  -  Fire  Control  System. 
The  final  recommended  approach  for  the  fire 
control  system  trainers  consisted  of  three 
part  task  trainers  designed  to  operate  as  a 
suite . 


The  recommended  FCS  training  device  suite 
combines  an  Aircraft  Peculiar  Trainer  (APT) 
for  the  performance  of  Operational  Checkouts, 
a  2D/3D  Panel  for  Fault  Isolation  procedures, 
and  a  Corrective  Actio**  a  Trainer  (CAT)  for 
Corrective  Actions  and  General  Maintenance 
tasks  (See  Figure  2).  Each  training  device 
can  be  operated  as  a  separate  trainer  and  will 
be  described  according  to  their  physical  and 
functional  characterist ics  in  the  following 
paragraphs. 


Figure  3.  Aircraft  Peculiar  Trainer 
Fire  Control  Sytem. 

Operational  checkouts  and  fault 
indications  require  observable  indications  on 
equipment  within  the  cockpit.  These 
observables  are  called  equipment  feedback.  In 
order  to  replicate  this  feedback  in  the 
training  environment,  training  software 
controlling  the  APT  is  a  mathematical  model  of 
the  operational  software  of  the  components 
used  in  the  maintenance-related  tasks. 

■"raining  software  will  be  modeled  with  the 
level  of  detail  necessary  to  perform  required 
operational  checkouts. 

Software  will  provide  at  a  minimum,  the 
requirements  called  for  by  the  appropriate  job 
guide  steps  for  operational  checkouts  as 
identified  and  annotated  in  the  functional 
specifications . 
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Applicable  cues  and  malfunction  codes  as 
called  for  by  the  selected  fault  codes 
described  in  the  functional  specifications 
will  be  provided  by  an  interface  with  an 
instructor  station.  The  instructor  will  have 
the  capability  of  inserting  the  preselected 
fault  codes  from  the  list  provided  in  a  menu 
format.  The  inserted  faults  will  provide 
signal  interruptions  to  the  training  software 
which  will  translate  into  the  non-observance 
of  expected  feedback  and  indicate  to  the 
student  that  a  malfunction  has  occurred  with  a 
malfunction  code.  The  instructor’s  fault 
insertion  capability  will  be  further  detailed 
with  the  description  of  the  instructor 
station. 

Software  will  also  be  provided  to  monitor 
any  student  activity  which  would  cause  injury 
to  personnel  or  damage  to  equipment.  A  visual 
and/or  audible  alert  will  be  automatically 
presented  via  an  interface  with  an  audiovisual 
prompter,  e.g.,  rear-projection  screen. 

•  2D/3D  Panel  for  Fault  Isolation 

The  2D/3D  Panel  will  consist  of  a  flat 
panel  fastened  on  metal  frames  mounted  on 
casters.  The  flat  panel  will  contain  those 
required  components  with  which  the  student 
would  interact  in  order  to  satisfy  hands-on 
training  requirements  for  fault  isolation 
tasks.  These  components  are  described  as 
follows  and  are  illustrated  in  Figure  4. 
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Figure  4.  2D/3D  Panel 

Fire  Control  System  Trainer. 

Three  types  of  electrical  connectors  will 
be  displayed  on  the  flat  panel:  round, 
rectangular,  and  flat  multiple  termination 
connectors  (MTC) .  Each  electrical  connector 
will  have  above  it  an  LCD  display  that  will  be 
used  to  identify  the  desired  connector. 

The  multimeter  used  to  measure  voltage, 
current  and  resistance  must  replicate  the 
external  physical  charac terlst ics  of  the 
existing  test  equipment. 

Two  relay  sockets  will  be  represented  by 
contact  points.  The  number  and  Identification 
of  each  contact  point  will  be  representative 
of  actual  relay  sockets.  An  LCD  readout 
capability  above  each  relay  will  be  provided. 


The  2D/ 3D  Pa. el  will  be  used  for 
practicing  the  hands-on  training  (HOT) 
requirements  for  fault  Isolation  procedures. 
The  HOT  requirements  entail  use  of  the  fault 
isolation  manual  and  the  measurement  of 
voltage  current  and  resistance  on  electrical 
connectors,  relays  and  terminal  boards.  These 
components  are  represented  on  the  2D/3D 
Panel.  The  remaining  components  represented 
on  the  panel  are  for  ensuring  the  procedural 
continuity  of  the  fault  Isolation  process. 

Software  controlling  the  fault  isolation 
process  will  meet  the  requirements  as 
described  in  the  appropriate  fault  Isolation 
steps  for  those  selected  fault  codes  described 
in  the  specifications. 

Malfunction  selection  and  insertion  will 
be  done  via  the  instructor  station. 

The  student  will  have  the  capability  of 
calling  up  any  particular  e-lectrical 
connector,  relay,  terminal  board  or  circuit 
breaker  by  keying  in  on  the  keypad  the 
identification  number  which  will  subsequently 
be  displayed  on  the  LCD  readout  above  the 
corresponding  terminal  desired.  This  terminal 
would  then  have  the  same  functional  logic  as 
the  one  called  for  by  the  fault  isolation  step 
of  the  particular  fault  code  selected. 

The  student  will  also  have  the  capability 
of  calling  up  on  the  video  display  screen  a 
listing  of  all  the  components  that  need  to  be 
removed  or  installed  for  the  particular  fault 
code  selected.  He/she  would  then  select  the 
appropriate  component  corresponding  to  the 
component  in  the  fault  isolation  step  that 
needed  to  be  removed  or  installed.  The 
student  would  then  respond  via  the  keyboard  to 
indicate  the  desired  action  on  that  particular 
component.  Wiring  repairs  and  other  similar 
Corrective  Actions  will  be  treated  In  the  ;.ame 
manner  on  this  device. 

•  Corrective  Action  Trainer  (CAT) 

Since  the  hands-on  training  requirements 
are  identical  for  several  Line  Replacement 
Units  (LRU),  selected  components  have  been 
identified  as  those  which  need  to  be 
represented  on  the  CAT.  This  training  device 
is  Illustrated  in  Figure  5. 
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Figure  S .  Corrective  Action  Trainer 
Fire  Control  System. 
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Physical  characteristics  necessary  to 
satisfy  the  hands-on  training  requirements  for 
removal  and  installation  tasks  are  described 
in  the  speci f ications. 

•  Instructor  Station 

The  instructor  will  have  the  capability  of 
inserting  fault  indications  and  symptoms  into 
the  APT  prior  to  or  during  a  student 
performance  of  operational  checkouts. 

The  instructor  will  have  the  capability  of 
selecting  a  particular  fault  code,  choosing 
which  Corrective  Action  the  student  is  to 
perform,  and  inserting  the  fault  isolation 
logic  Into  the  2D/3D  Panel. 

The  instructor  station  will  also  enable 
the  instructor  to  input  certain  parameters 
necessary  for  the  development  of  information 
that  is  normally  stored  in  the  operational 
software.  For  example,  in  order  for  the  APT 
to  compute  and  display  magnetic  heading  on  the 
compass  card,  the  instructor  must  have  the 
capability  of  entering  true  heading,  magnetic 
variation  and  ground  track, 

A  CRT  design  with  keyboard  will  fulfill 
the  instructor  station  physical  requirements. 

Hardware  Selection  ~  Armament  System.  The 
final  recommendations  for  the  Weapon  release 
system  was  a  single  trainer  to  represent  those 
portions  of  the  aircraft  associated  with  the 
weapons  release  systems. 

USAF  students  enrolled  in  the  FTD 
Organizational  Maintenance  courses  for  the 
F-16  Weapons  Maintenance  Technician  (AFSC 
462X0)  are  composed  of  recent  graduates  of  the 
Basic  Weapons  School  at  Lowry  AFB,  Colorado, 
and  technicians  undergoing  cross-training  from 
another  aircraft  to  the  F-16.  The  need  to 
provide  these  students  with  hands-on  training 
to  support  course  training  objectives  In  the 
following  areas  of  instruction  was  verified: 

•  Stores  Management  System 

•  Stores  Management  System  MUX  BUS 

•  M61A1  Gun  System 

•  Weapons  Suspension  System 

The  training  provided  in  these  systems 
includes  procedures  for  accomplishing 
Operational  Checkouts,  Fault  Isolation, 
Corrective  Actions,  and  General  Maintenance 
activities.  The  training  device  requirements 
necessary  to  provide  these  students  with 
adequate  hands-on  training  capabilities  were 
determined  and  listed  during  t he  task  analysis. 

•  Training  Device  Suite 

The  recommended  Armament  Systpm  Trainer 
shall  be  one  device  consisting  of  three 
platform  mounted  hardware  modules  which  are 
electrically  and  electronically 
Interconnected.  These  modules  are  the  APT, 
2D/3D  Panel,  and  instructor  Station.  System 
simulation  and  component  control  shall  he 
accomplished  through  a  trainer  computer 
program  which  models  the  aircraft  operational 


software  and  provides  correct  component 
response  and  subsystems  interaction.  The 
conceptual  arrangement  of  the  Weapons  Control 
System  Trainer  is  depicted  in  Figure  *>.  A 
more  specific  delineation  of  the  trainer's 
physical  and  functional  characterise i cs 
f ol lows . 


Figure  6.  Training  Device  Suite 
Weapons  Control  System. 

•  Physical  Characteristics 

The  APT  was  described  to  conform 
externally  in  size  and  shape  to  the  fuselage 
section  of  the  F-16  which  contains  the  M61A1 
gun  system  and  the  centerline  weapons 
station.  It  contains  the  M61A1  gun  system 
complete  with  the  Ammunition  Handling  System 
and  related  components,  i,e.,  handcrank,  hoist 
assembly,  dummy  rounds,  gun  port,  access 
panels  and  doors  plus  those  additional  items 
normally  associated  with  gun  installation  and 
operation.  Electrical  and  hydraulic 
provisions  were  specified  to  ensure  proper  gun 
and  ammunition  handling  systems  operation  for 
training  purposes.  Safety  systems  and 
equipment  specified  in  the  Gun  Safe  for 
Maintenance  requirements  shall  be  provided.  A 
stub  wing  formed  to  the  F-16  wing 
conf igurat ion  and  containing  Weapons  Station 
#3  attached  to  the  left  side  of  the  fuselage 
section.  The  wing  attaching  points  were 
designed  to  allow  stub  wing  detachment  for 
ease  of  shipping. 

The  wing  station  was  described,  together 
with  the  centerline  weapons  station,  weapon 
pylons  and  the  required  interface  units,  a  .d 
related  matrix  assemblies.  Electrical 
I nterconnect i ons  which  conform  to  the  F-16 
Installation  shall  he  provided  with  the 
weapons  stations.  Figure  7  depicts  the 
conceptualized  APT  (modified). 
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Figure  7.  Aire  rat t  Peculiar  Trainer 
Weapons  Control  S vs  tom. 
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A  2D/3D  Panel  consists  of  the  cockpit 
controls  and  components  required  to  provide 
Weapons  Control  System  hands-on  training. 

These  components  were  arranged  on  the  2D/3D 
Panel  and  visually  related  to  their 
corresponding  location  on  a  top  view  of  the 
F-16  cockpit  consoles.  The  2D/3D  Panel 
comprises  the  student  station  for  operational 
control  of  the  Weapons  Control  System 
Trai ner . 

Proposed  panel  placement  of  components  are 
illustrated  in  Figure  8.  All  electrical  and 
electronic  connections  required  to  ensure 
proper  component  operation  individually  and  as 
part  of  an  integrated  system  were  provided. 
Electrical  and  manual  safety  interlocks, 
guards,  covers,  etc.  were  included  where 
required  to  provide  proper  system  operation 
and/or  protection. 


Figure  8.  2D/3D  Panel. 

The  instructor's  station  will  be  located 
out  of  direct  view  of  the  student  but  will  be 
situated  so  that  the  student  can  be  seen  by 
the  instructor  while  at  the  station.  The 
instructor  station  will  be  used  to  control  the 
training  device  for  normal  and  emergency 
operat ion. 

•  Functional  Characteristics 

The  Armament  System  Trainer  shall  provide 
the  subsystem  functions  and  interactions 
needed  to  allow  realistic  performance  of  the 
weapons  system  operational  checkouts  listed  in 
the  specifications. 

The  trainer  shall  contain  the  capabilities 
to  allow  selective  insertion  of  weapons  system 
faults  into  the  operational  program.  Correct 
fault  symptoms  shall  he  displayed  by  the 
subsvstem( s )  affected. 

These  laults  require  use  of  test  equipment 
to  a<complish  voltage,  resistance  and 
continuity  checks.  Interpretation  and 
clearing  of  fault  codes  (MFL's)  is  required  in 
addition  to  performing  operational  checks 
where  called  out  in  the  T.O.s.  Trainer 
operation  will  allow  complete  performance  of 
those  fault  Isolation  procedures  necessary  to 
determine  the  fault(s)  and  initiate  corrective 
action. 


With  the  exception  of  the  Throttle  Crip 
Assembly,  the  APT  section  of  the  Weapons 
Control  System  Trainer  will  contain  the 
capabilities  necessary  to  satisfy  the 
corrective  action  ( remove/ 1 nsta 1 1 )  and 
follow-on  maintenance  requirements  for  the 
components  selected  by  USAF  SME ' s  in  the 
expert  panel  session,  and  listed  in  the 
spec i f i cat  ion . 

Additionally,  capabilities  for  the 
following  M61A1  Gun  System  checks, 
adjustments,  and  servicing  not  otherwise 
specified  shall  be  included. 

General  maintenance  procedures  associated 
with  the  Weapons  Control  System  revolve 
largely  around  component  location,  access  door 
operation/panel  removal  and  installation, 
connection  and  d isconnec t i on  of  ground 
servicing  equipment  (electrical,  cooling, 
bleed  air),  systems  power  up/power  down, 
memory  loading,  test  unit  preparation,  and 
Weapons  System  initialization.  These 
capabilities  must  reside  within  the  Armament 
System  Trainer. 

Correc  ive  action  (i.e.,  remove/install) 
hands-on  training  requirements  exist  for  the 
Throttle  Grip  Assembly  because  of  the  large 
number  of  small  items  which  compiise  its 
mechanical  mechanism  and  their  criticality  to 
its  proper  functioning.  Add . v i onal ly ,  the 
removal  and  installation  procedure  is 
complicated  because  of  the  relative 
inaccessibility  of  the  throttle  grip  as 
installed  in  the  F-16.  Incorporating  the 
physical  restrictions  that  surround  its  normal 
installation  appears  to  be  feasible  only  in  a 
Corrective  Action  Trainer  (CAT)  that  is 
separate  from  the  Weapons  Control  System 
T  rainer . 

The  CAT  will  be  a  lightweight,  portable* 
tabletop  type  trainer  housed  in  a  protective 
case  with  detachable  cover.  Figure  9  contains 
a  conceptual  presentation  of  the  Corrective 
Action  Trainer. 


Figure  9.  Corrective  Action  Trainer 
Weapons  Control  System. 
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Software  Selection.  Software  design 
selection  was  somewhat  more  complex,  and  was 
based  on  the  training  need  of  the  Individual 
groups  of  tasks.  The  operational  checks  for 
the  types  are  to  be  done  from  applicable 
technical  orders,  but  there  was  a  requirement 
for  the  devices  to  replicate  actual  aircraft 
Indications  If  the  trainee  deviated  from  the 
technical  order  procedures.  System  modeling 
of  each  component  was  necessary  to  meet  this 
requirement.  For  the  fault  isolation  (FI) 
trainer,  the  table  driven  module  was 
acceptable,  since  each  fault  has  specific 
readings  for  given  locations.  The  trainee  Is 
responsible  for  following  the  manual  and 
selection  the  proper  locations.  Update  of  the 
FI  trainer  requires  only  an  enlarging  of  the 
table  driven  matrix,  since  faults  would  not 
Interact  with  each  other.  Operational 
software  models  were  used  on  the  armament 
trainer  since  the  computer  which  controls  the 
proposed  trainer  is  also  taken  from  the 
aircraft  and  Interfaces  with  pylons,  gun  and 
control  systems. 

SUMMARY 

There  were  several  advantages  to  selecting 
these  devices,  which  have  been  reiterated 
several  times  since  acceptance  by  the  Air 
Force.  These  are  very  cost  effective  trainers 
for  three  reasons.  First,  they  are  relatively 
simple,  designed  to  teach  only  what  was 
required  (hands-on  training),  relegating  other 
instructional  requirements  to  more  cost 
effective  media.  Their  simplicity  also 
resides  in  that  these  devices  were  designed 
with  only  the  necessary  fidelity  required  for 
the  accomplishment  of  training.  Another 
factor  contributing  to  the  devices'  simplicity 
Is  Inherent  within  the  established  hands-on 
training  requirements  for  each  category  of 
tasks  Involved  with  the  Fire  Control  and 
Armament  systems.  By  Identifying  the  type  of 
student  behavior  (HOT  requirements)  common  to 
as  many  tasks  as  possible  for  each  system,  you 
only  need  a  representative  sample  of 
components  to  teach  the  hands-on  skills 
Instead  of  the  multitude  of  components  that 
are  available.  The  Fire  Control  and  Armament 
system  device  concepts  teach  all  necessary 
skills,  but  do  so  with  a  minimum  number  of 
components  and  with  only  the  required  fidelity 
and  no  more. 

Second,  these  training  devices  can  be 
updated  with  relative  ease  and  do  not  render 
the  entire  training  suite  inoperable  from 
either  a  hardware  or_  software  standpoint 
during  the  update  work.  This  is  so  from  a 
hardware  standpoint  because  each  device  is  a 
stand  alone  system,  and  from  a  software 
standpoint  because  first,  the  functions  of 
each  subsystem  and  component  are  Individually 
mathematically  modeled  to  reflect  the 
operating  characteristics  and  second,  a 
separate  procedures  monitoring  software 
provides  for  the  type  of  augmented  feedback 
the  student  would  need  in  the  event  of  an 
Improper  procedure  or  unsafe  action.  This 


software  approach  Is  a  key  factor  In  ensuring 
the  training  devices'  cost  effectiveness  given 
the  operational  and  administrative  constraints 
in  the  Air  Force.  The  following  Is  an  example 
of  how  changes  In  the  aircraft  affect  the 
training  device  configuration  and/or  the 
instructional  content  the  student  receives. 

Any  Engineering  Change  Proposals  (ECP)  during 
the  life  cycle  of  the  F-16  may  affect  not  only 
subsystem/component  configurations  but  also 
the  Technical  Order  (TO)  system.  The  student 
uses  the  TOs  to  perform  operational  checks 
using  Job  Guides  or  to  troubleshoot  using  the 
Fault  Isolation  manuals.  The  software 
modeling  approach  In  this  case  is  most 
flexible  and  easier  to  update  because 
subsystems/components  are  modeled  individually 
and  the  software  program  can  be  done  In 
modules.  The  separate  procedures  monitoring 
software  which  is  based  on  the  steps  called 
out  for  In  the  TOs  would  be  subject  to  change 
If  procedures  in  the  TOs  would  change  as  a 
result  of  the  ECP.  However,  since  the 
procedures  monitoring  software  is  separate 
from  the  software  which  gives  component 
feedback  to  the  student  (as  opposed  to 
augmented  feedback)  the  Impact  of  the  inherent 
delays  in  publication  cycles  of  the  TOs 
resulting  from  a  change  In  procedures  on 
training  effectiveness  will  be  minimal.  The 
student  would  still  be  able  to  receive  the 
same  feedback  he/she  would  be  getting  in  the 
operational  environment  pending  the  update  of 
the  technical  order  system. 

Third,  considerable  time  savings,  which 
invariably  can  be  translated  Into  cost 
savings,  resulted  not  only  because  of  the 
streamlined  approach  previously  outlined  but 
mainly  because  USAF  User  Command  personnel 
were  heavily  Involved  from  the  beginning  In 
the  design  and  selection  processes,  and  were 
able  to  give  unofficial  acceptance  of 
conceptualization  and  design  far  In  advance  of 
the  final  recommendations. 

Finally,  the  functional  requirements  for 
the  Fire  Control  and  Armament  systems  are 
presently  being  used  as  a  basis  for  developing 
a  Prime  Item  Development  Specification  for  the 
manufacture  of  required  training  devices.  In 
addition,  the  authors  are  involved  in  a 
follow-on  contract  issued  to  assist  the 
training  device  manufacturer  In  ensuring  the 
training  devices  meet  established  training 
requirements. 
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-  Training  Capabilities 

"The  Facility  Part  of  the  Equation" 

By 

Jerome  S.  Kamchi  (Configuration  Control  Mgr) 
and 

Weldon  "Bud"  Dube'  (Facility  Engineer) 

Air  Force  Human  Resources  Laboratory  (AFHRL/OTS)  WAFB,  AZ. 

ABSTRACT 

The  theme  of  increased  readiness  through  training  has  an  inherent  assumption  that  adequate 
facilities  either  exist,  can  be  modified,  or  can  be  built  to  house  computerized  training  devices.  Too 
often  adequate  facilities  do  not  exist  or  require  long  lead  times  to  acquire.  Training  capabilities 
can  become  a  myth  to  the  realities  of  not  having  an  adequate  facility  or  of  having  modern  training 
equipment  fail  because  of  facility  deficiencies  such  as  high  temperatures  and  power  spikes.  But  what 
are  adequate  facilities  for  computerized  training  devices,  and  how  do  we  acquire  them?  This  paper  will 
review  the  time  phasing  and  types  of  funding  available  within  the  Department  of  Defense  for 
construction  projects,  design  concepts  of  a  flexible  modular  training  building  including  security  and 
environmental  considerations.  Without  understanding  the  time  phasing  for  acquisition  of  training 
facilities,  the  effectiveness  of  training  devices  can  be  reduced  to  zero. 


1.  ACQUISITION  OF  NEW  FACILITIES  VIA  THE 
MILITARY  CONSTRUCTION  PROGRAM  (MCP~T 

Agencies  within  the  Department  of  Defense 
acquire  new  facilities  via  the  MCP  (3300) 
appropriation  and  in  the  Air  Force  in  accordance 
with  AFR  86-1.  The  lead  time  for  a  project 
greater  than  one  million  dollars  is  usually  five 
years  from  planning  to  completion  of 
construction.  Thus  in  early  1983  the  planning 
must  be  done  for  a  Fiscal  Year  (FY)  86  funded 
facility  to  be  completed  in  1987.  The  following 
are  illustrative  FY  86  MCP  MILESTONES  shown  on 
Figure  1: 

In  1983  the  user  identifies  a  requirement, 
receives  approval  to  proceed  with  detail 
studies,  prepares  a  Military  Construction  Data 
Sheet  DO  Form  1391,  starts  a  design  criteria 
Study/project  book; 

•  The  Major  Command  (MAJCOM)  includes  the 
project  in  the  1985-89  submission  in  July  1983. 
It  Is  mandatory  the  facility  project  be  35X 
designed  by  Sept  84  for  an  FY86  MCP.  To  obtain 
this  milestone  the  project  must  be  included  in 
the  1985-89  plan  so  design  can  be  started  in 
early  1984; 

•  Major  Command  (MAJCOM)  1986-1990  Budget 
Review  Jul  84; 

Air  Force  and  Office  of  the  Secretary  of 
Defense  (OSD)  Review  Sept -Dec  84; 

•  Congressional  Review  and  Approval  -  Jan-Sept 
85; 

•  FY86  Appropriation  becomes  Law  on  1  Oct  85. 

•  Other  MILESTONES  would  reflect  a  minimum 
60-day  period  to  select  and  hire  an 
architect-engineer  to  design  the  facility,  and  a 
minimum  60-day  period  to  award  a  construction 
contract  for  a  one  to  two-year  construction 
effort . 


Congressional  approval  and  MAJCOM  review 
dates  do  vary  but  the  chart  reflects  the 
milestone  sequences. 

Minor  Construction  Projects.  Construction 
projects  for  a  single  undertaking  which  cost 
less  than  one  million  dollars,  and  provide 
complete  and  useable  facilities  or  improvement 
to  an  existing  facility  are  Minor  Construction 
Projects. (1)  They  are  called  specified  minor 
construction  if  identified  in  the  annual 
Congressional  submittal.  These  require  the  same 
lead  time  as  the  MCP  described  above.  A  minor 
construction  project  considered  exigent  (or 
urgent)  can  be  submitted  for  approval  at  the 
time  the  requirement  is  defined.  Upon  approval 
of  the  Major  Command  and  HQ  USAF/LEE  the 
facility  design  can  be  started  and  upon 
completion  of  the  design,  funds  can  be  requested 
for  construction.  This  is  often  a  one  year 
cycle.  The  difference  between  the  specified  and 
exigent  minor  construction  is:  1)  the  approval 
level,  2)  the  time  required  for  approval,  and  3) 
the  intense  competition  for  the  limited  funds  in 
the  exigent  category.  Figure  2  shows  the 
approval  levels  for  an  Air  Force  Human  Resources 
Laboratory/Operations  Training  Division 
(AFHRL/OT)  MCP,  Minor  Construction  and  Eouipment 
Installation  Project. 

For  all  MCP  projects  the  DD  Form  1391  must 
show:  a  well  defined  requirement  reflecting 
program  funds  and  manpower;  funds  and  schedules 
for  equipment  and  construction  completion; 
detail  construction  costs;  location  at  a 
specific  base  or  site;  size  and  the 
environmental  impact  of  the  new  building.  A 
design  criteria  study  for  R&D  facilities  and  a 
project  book  for  MCP  will  provide  most  of  this 
information.  After  the  project  is  submitted  to 
Congress,  to  the  House  and  Senate  Authorization 
and  Appropriation  Committees,  the  location,  size 
and  cost  cannot  be  changed. 

Another  method  of  obtaining  an  adequate  R&D 
Training  or  Simulator  capability  is  to  modify  an 
existing  building  in  accord  with  the  criteria  of 
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AFR  80-22  Par  3,  "Installing  R&D  Equipment." 
False  floors,  shielding,  special  foundations, 
secondary  utility  work,  air  conditioning  and 
mechanical  ventilation  are  included  in  an  R&D 
equipment  installation  project. (2)  These 
modifications  are  accomplished  with  R&D  funds. 
Another  method  is  to  use  maintenance  funds  to 
modify  an  existing  structure  but  this  is  limited 
to  $200,000. 

2.  FACILITY  CONSIDERATIONS 

A  training  simulation  facility  usually 
consists  of  four  areas:  Computer  area; 
Simulation  or  Training  area;  Office  area;  and 
Support  area  (Figure  3).  The  COMPUTER  AREA 
should  contain  features  such  as:  tight-fitting 
raised  floors  with  static-free  sectional 
carpeting;  air  conditioning  and  humidity  control 
in  accordance  with  the  equipment  manufacturer's 
specifications;  an  electrical  system  with 
dedicated  electrical  circuits  and  circuit 
breakers  for  the  computers,  a  separate  circuit 
for  lighting  and  receptacles  and  other  building 
power,  and  a  grounding  system;  an  AC  power 
protection  system  for  the  entire  electrical 
system;  fire  protection  system  with  detection 
alarms  for  smoke  and  heat  and  a  Hal  on  (1301) 
protection  system(3);  safety  items  such  as 
battery  operated  emergency  lights  and  electrical 
cutoff  switches. The  Halon  system  provides  a  non 
combustable  gas.  There  must  be  enough  Halon 
avaiable  to  fill  the  room  and  deprive  a  flame  of 
oxygen.  The  system  release  points  should  be 
located  close  to  expensive  as  well  as 
combustable  materials  in  the  training  area  ie., 
hydraulic  fluids,  petrochemicals,  cockpits,  crew 
stations,  and  the  computers.  Halon  is  used  for 
fire  protection  instead  of  water  and  avoids  the 
possibility  of  water  damage  to  computer 
equipment  and  electrical  shocks  to  people  in  the 
event  of  an  emergency.  Of  course  the  room  with 
Halon  must  be  evacuated  in  the  event  of  any 
emergency.  For  new  buildings  the  computer  area 
can  have  a  18  inches  sunken  floor  with  the 
raised  computer  floor  on  the  same  level  as  the 
corridors  and  other  rooms.  This  avoids  the  need 
for  ramps  and  steps.  The  18  inches  space  under 
the  floor  serves  as  an  air  conditioning  plenum 
to  provide  cold  air  into  the  bottom  of  the 
computers  and  as  an  electrical  trough  for  all 
the  interconnecting  cables  and  wires.  The  need 
for  a  tight-fitting  floor  with  static-free 
carpeting  is  to  retain  the  cold  air  in  the 
plenum  for  air  conditioning  purposes  but  also  to 
prevent  the  computer  room  from  becoming  a 
refrigerator:  A  comfort  zone  temperature  is 

72°+2°  but  computer  cooling  temperature 
requirements  may  be  as  low  55°+2°.  One 
solution  for  having  comfortable  work  areas  in 
computer  rooms  is  to  have  terminals  and  work 
space  on  the  concrete  floor  level  rather  than 
the  raised  floor  level.  The  floor  to  ceiling 
height  in  a  computer  room  should  be  a  minimum  of 
eight  feet.  Separate  circuits,  grounding  system 
and  AC  power  protection  systems  are  considered 
essential  to  establishing  and  maintaining 
electrical  integrity  for  computer  operations. 

The  Simulator  or  Training  Areas  should 
contain  such  features  as:  T)  air  conditioning 


and  humidity  control  in  accord  with  the 
eouipment  manufacturer's  specifications  and  this 
is  often  not  as  cold  as  the  computer  area,  ?! 
sufficient  space  from  the  bottom  of  the 
simulator  or  other  training  equipment  and  the 
floor.  This  is  for  maintenance  purposes  and  for 
accessibility  to  cables;  3)  the  same  electrical, 
fire  protection  and  safety  considerations  as 
noted  for  computer  areas. 

The  Office  and  Support  Areas  require  similar 
electrical  services  noted  for  computer  areas. 

To  have  both  areas  as  flexible  as  possible,  the 
use  of  electrical  equipment  such  as  desk  top 
computers,  CRT  Terminals,  word  processors  and 
printers  should  be  considered  in  the  location  of 
receptacles  and  distribution  of  power  loads. 

The  interior  decoration  of  the  office  areas 
should  reflect  a  pleasing  environment  with 
proper  lighting  (see  section  on  lights! 
furniture,  colors,  use  of  paneling  and  rugs. 
Studies  at  TRW  Inc.  indicated  a  high  increase  in 
programmer  productivity  when  working  in  a 
pleasant  environment  and  more  comfortable 
offices. (4)  The  institutional  green,  gray  or 
white  cinderblock  walls(5)  and  gray  office 
furniture  next  to  the  radiator  is  not 
recommended.  It  does  not  stimulate 
productivity,  longevity,  or  employee  morale. 

The  Air  Force  Standard  of  130  square  feet  per 
person  in  office  areas  is  encouraged.  The  use 
of  modular  office  funiture  with  sound-absorbing 
fabric-covered  partitions  could  reduce  this  to 
100  square  feet  per  person. 

Before  reviewing  Design  Concepts,  the 
relationship  between  the  User  and  the  Architect 
-  Engineer  (A-E)  should  be  explained.  The  A-E 
will  take  the  Users  requirements  (routine  and 
mission  necessary)  and  develop  a  layout  and  plan 
for  a  facility  to  accomplish  the  mission.  Too 
often  the  User  thinks,  "I'll  wait  for  the  A-E  to 
tell  me  what  I  need."  The  design  criteria  type 
of  study  will  define  what  is  needed.  The  User 
should  specify  his  mission  requirements  which 
include  the  technical,  administrative,  support, 
health,  welfare  and  morale  aspects  of  work  and 
training  areas  for  people  to  effectively  use  for 
8  to  10  hours  a  day.  From  the  very  beginning 
the  User  should  work  closely  with  the  A-E  and 
the  Base  Civil  Engineer  to  obtain  a  facility 
that  enhances  the  training  mission. 

Design  concepts  should  include  the  following 

a)  Flexible  and  Expandable  Areas.  The  four 
areas  discussed  should  be  designed  as  separate 
rectangular  or  square  sections  with  each  section 
having  expansion  capabilities  both  interior  and 
exterior  to  the  building.  No  one  section  should 
be  totally  surrounded  by  another  section.  There 
should  be  at  least  two  exterior  areas  for 
external  expansion  for  each  section.  Figure  3 
reflects  this  concept  in  a  two-story, 
four-section  simulator/training  building.  The 
computer,  simulator,  and  training  areas  are 
located  on  the  below  ground  level  floor  to  use 
the  earth  to  contain  electromagnetic  radiations 
and  emissions  from  the  equipment  as  well  as  for 
physical  security  and  environmental  control. 
Another  configuration  would  be  the  U-shape 
building  that  can  be  expanded  into  a  square. 


b)  Environmental  Considerations. 
Lighting-Electromagnetic  Radiation  and  its 
Psychophysiologica!  Impact. 

Extensive  clinical  and  laboratory  data 
indicate  that  profound  psychological  and 
physiological  effects  can  be  routinely  induced 
in  humans,  animals  and  plants  by  exposing  them 
to  the  radiation  emissions  of  conventional  "Cool 
White"  fluorescent  lamps,  in  contrast  to 
fluorescent  lamps  which  simulate  the 
electromagnetic  spectra  of  terrestrial  solar 
radiation  in  both  the  ultraviolet  (UV)  and 
visible  wavelengths. (6)(7)8){9)  Ordinary  window 
glass  reflects  or  absorbs  much  of  the 
"biologically  active"  spectra  of  natural  outdoor 
sunlight.  Having  closed  windows  and  rooms 
without  windows  has  sealed-off  these  spectra. 

The  psychophysiological  manifestations  of 
spectral  deficiencies  include:  increased  stress 
and  fatigue,  increased  levels  of  depression, 
increased  blood  pressure  and  serum  cholesterol 
levels,  and  Vitamin  0  deficiency. 

Solar  radiation  can  be  specifically 
defined  and  it  is  rather  stable  in  the 
proportion  of  radiation  emitted  in  the  near 
ultraviolet  (320-380  nanometer-nm)  and  visible 
(380-750nm)  regions,  whereas  the  middle 
ultraviolet  (290-320nm)  region  varies  with  the 
angle  of  the  sun.  The  specification  of 
artificial  light  sources  for  the  simulation  of 
the  full  visible  and  invisible  balanced 
ultraviolet  spectra  of  terrestrial  solar  global 
radiation  (i.e.,  sun  +  sky)  for  use  in  general 
indoor  illumination  are  as  follows  (10): 

Correlated  Color  Temperature: 

5500  to  65CuK 

Color  Rendering  Index:  90  or 

greater 

Near  Ultraviolet  Radiation: 

(UVA,  320  to  380  nm)  220+60  microwatts/ lumen 

Middle  Ultraviolet  Radiation: 

(UVB,  290  to  320nm)  15+  microwatts/ lumen 

Fluorescent  lamps  which  simulate  natural 
outdoor  sunlight  in  both  the  visible  and 
ultraviolet  spectra  are  highly  recoirmended .  At 
AFHRL/OT  we  are  testing  the  "Vita  lite"  of  the 
Duro-Test  Corporation.  If  obstacles  to  learning 
such  as  fatigue,  headaches  and  eyestrain  can  be 
minimized  by  optimizing  the  indoor  electro¬ 
magnetic  environment  with  daylight  simulating 
lamps,  the  cost  benefit  trade-offs  will  be  very 
significant. 

The  building  exterior  such  as  the 
terrain,  trees,  shrubs  should  be  utilized  to 


cl  Energy  and  conservation.  The  energy 
conservation  initiatives  are  driven  by  actions 
involving  energy  system  optimization.nl)  There 
will  be  changes  in  the  design  practice  with 
"life-cycle  costing  and  sensitivity  analysis 
becoming  very  important. “(12)  Computer-Aided 
Engineering  and  Architectural  Design  System 
(CAEADS)  as  developed  by  the  US  Army  Corps  of 
Engineers  will  have  far-reaching  benefits. (131 
Consideration  should  be  given  to  siting  the 
building  with  few  windows  along  the  southern  or 
western  side  of  the  building  in  order  to  reduce 
heating  and  air  conditioning  costs.  The  offices 
and  support  areas  where  sunlight  may  be  desired 
should  be  located  in  the  NE  and  NW  side  of  a 
building  with  windows  on  the  North  and  East 
sides  of  the  building.  High  bays  with  no 
windows  should  be  located  on  the  west  side  of 
buildings  and  in  a  two-building  complex  one 
building  should  be  located  to. provide  shade  to 
the  other  one.  The  Naval  Facility  Engineering 
Command  has  a  five-step  plan  to  save  energy 
which  includes  use  of  outside  air  instead  of 
return  air  on  an  air  conditioning  system  when 
conditioning  outside  air  requires  less  energy 
than  using  the  return  air.  (14)  The  AFHRL/OT 
Laboratory  Annex  includes  this  feature.  Cost 
trade-off  studies  between  using  commercially 
available  power  with  a  low  investment  cost 
versus  generating  power  are  recommended.  The 
Air  Force  has  done  both.  Power  line  problems 
consist  of  blackouts,  brownouts,  fluctuating 
voltage  and  noise  or  transients  superimposed  on 
the  line.  The  first  problems  can  be  solved  with 
Uninterruptible  Power  Systems  (UPS).  All  Air 
Force  UPS  are  centrally  procured  through  Air 
Force  Logistics  Conmand  (AFLC)  channels  from  the 
Chesapeake  Division,  Naval  Facilities 
Engineering  Command  under  a  fixed  price, 
indefinite  quantity  contract  for  the  following 
KVA  sizes:  50,  100,  200,  250,  400  and  500.(15) 
Too  frequently  the  noise  or  transient  problem  is 
overlooked.  For  training  facilities  with  a  high 
reliance  on  computers  it  is  essential  to  have  an 
AC  power  protection  system.  The  degrading 
effects  of  short  duration  transient  voltages  on 
solid-state  semi-conductors  and  integrated 
circuits  are  of  prime  concern  to  the  users  of 
electronic  computers  and  equipment.  The  effects 
can  inflict  immediate  and  extensive  damage  to 
vital  circuitry  to  on-line  equipment  and  can 
result  in  equipment  failures.  The  associated 
costs  for  replacement  equipment  and  delayed 
training  or  the  research  missions  can  be 
prevented  with  an  AC  Power  Protection  System 
with  the  technical  features  and  Electrical 
Specifications  covered  in  Report-AFHRL-TP-82-38 
by  Mr  Weldon  M.  Dube1.  The  desired  features  are 

1)  Automatic  status  and  monitoring 
capabilities 


take  advantage  of  the  existing  environment 
rather  than  treat  it  as  an  enemy  to  be  overcome 
with  bulldozers  and  extra  air  conditioning. 
Reprocessed  water  can  be  considered  for  use 
exterior  to  the  building  for  such  items  as 
watering  lawns  or  other  esthetic  features.  In 
the  southern  part  of  the  county  the  use  of  solar 
and  geothermal  energy  devices  should  also  be 
considered. 


2)  Resettable  digital  counter  for 
transient  readout  with  36  to  48  hours 
ride-through  if  power  is  absent 

3)  Remote  control  panel  with  fully 
independent  operating  controls,  status  indicator 
and  digital  readout 

4)  Field  repairable  "downtime"  of  less 
than  one  hour  so  that  on-hand  replacement 
modules  can  be  rapidly  installed. 

5)  Protection  available  100*  of  the 
time  even  if  the  utilities  are  blacked  out  and 
no  power  is  available  to  the  facility. 
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There  are  siqnal  line  protectors  expressly 
designed  to  protect  signal/data/telephone  lines 
from  transport  over-voltages  caused  h_y  lighting, 
heavy  machi nery,  electric  motors,  generators, 
etc.(16)The  small  investment  of  5  to  25,000 
dollars  >n  AC  power  protection  systems  is 
considered  essential  when  you  relate  the  impact 
of  a  power  or  equipment  failure  to  the  traininq 
mission  i.e.,  lost  time  and  additional  costs  to 
repeat  the  training  if  schedules  permit; 
completing  training  without  repeating  the  "lost" 
portions  because  the  training  schedules  can  not 
be  slipped;  the  time  and  cost  to  replace  damaged 
equipment  could  mean  a  major  rescheduling  of 
several  classes;  and  the  increased  potential  for 
accidents  in  darkened  training  areas. 

To  maintain  desired  temperature  control  in 
the  buildings,  it  is  important  to  have  the 
thermostat  control  accessible  only  to  facility 
engineer/maintenance  personnel  and  not  in  public 
areas  where  anyone  can  make  changes.  Most  Air 
Force  bases  use  an  Energy  Monitoring  Control 
System.  Other  energy  conservation  techniques 
includes  turning  lights  off  in  all  areas  that 
are  to  be  vacant  for  more  than  several  minutes; 
i.e.,  offices,  conference  rooms,  support  areas, 
and  even  restrooms  in  the  evening.  A  trade-off 
study  between  fluorescent  lamp  replacement  and 
electric  costs  has  shown  that  any  time  a  room  is 
to  be  vacated  for  more  than  a  couple  of  minutes, 
the  fluorescent  light  should  be  turned  off. (17) 

A  free  hot  water  making  machine  can  reduce  or 
eliminate  the  number  of  individual  coffee  making 
machines  and  mini-kitchens  in  offices. 

d)  Security.  The  two  major  systems  for 
security  are  physical  and  electronic.  The  type 
of  problem  or  threat  must  be  identified  when 
selecting  protection  devices.  Is  it  an  external 
enemy  or  is  it  an  internal  problem?  Physical 
Compromise  is  a  compromise  of  information  by 
loss,  theft,  capture,  unauthorized  viewing  or 
photography,  recovery  by  salvage  or  physical 
means.  Physical  security  protection  involves 
techniques  as  1)  key  locks,  2)  electronic  card 
keys  with  photo  identification  which  give 
irrmediate  printed  reports.  Equipment  failures 
of  key  locks  are  more  probable  than  intrusion 
tampering.  3)  security  guards  which  require 
three  shifts  for  24-hour  protection  plus 
replacements  for  lunch,  rest  periods,  vacations 
and  illness.  4)  closed  circuit  TV  or  other 
detection  devices  to  monitor  intrusion  into  a 
building  as  well  as  for  rooms  with  high  value 
equipment  or  classified  data.  Designs  for  high 
security  locking  systems  and  secure  window 
barriers  will  be  published  in  the  Naval 
Facilities  Engineering  Command  Physical  Design 
Manual  (DM-13).(18)  Electronic  Security  is 
concerned  with  preventing  the  loss  of  or 
compromising  classified  data  via  electronic 
emanations.  A  compromising  emanation  is  an 
unintentional  data  related  or  intelligence 
bearing  signal  which,  if  intercepted  and 
analyzed,  discloses  the  classified  information 
transmitted,  received,  handled  or  otherwise 
processed  by  any  information-processing 
equipment.  We  should  note  there  is  a  National 
Policy  on  Control  of  Compromising  Emanations. 


To  appreciate  the  problems  of  electronic 
security,  the  followinq  is  a  brief  review  of 
definitions,  regulations,  possible  solutions  and 
assistance.  Definitions:  The  Physical  Control 
Zone  (PCZ)  is  the  spare  surrounding  equipment 
processing  classified  information  whirh  is  under 
sufficient  physical  and  technical  control  to 
preclude  a  successful  or  hostile  intercept  of 
any  classified  information  from  within  this 
space.  The  Controlled  Access  Area  c CAA 1  is  the 
complete  building  or  facility  area  under  direct 
physical  control  which  can  include  one  or  more 
limited  Exclusion  Areas  1  a  secured  room  for  RED 
information-processing  systems  eauipment  and 
wirelines),  and  controlled  BLACK  Eauipment  Areas 
or  any  combination  thereof.  Spares  within  a 
facility  which  are  not  under  direct  physical 
control  but  to  which  access  is  controlled 
I administrative  office,  halls,  restrooms)  are 
not  a  part  of  the  actual  CAA  but  are  considered 
as  a  part  of  the  overall  Physical  Control  Zone. 
RED/BLACK  is  a  concept  that  electrical  and 
electronic  circuits,  components,  equipments  and 
systems  which  handle  classified  plain  language 
information  in  electronic  siqnal  form  (RED)  must 
be  separated  from  those  which  handle  encrypted 
or  unclassified  information  (BLACK).  Under  this 
concept,  RED  and  BLACK  terminology  is  used  to 
clarify  specific  criteria  relatinq  to  and 
differentiating  between  such  circuits, 
components,  equipments  and  systems  and  the  areas 
in  which  they  are  contained.  Equipment  TEMPEST 
Radiation  Zone  (ETRZ)  is  a  zone  established  as  a 
result  of  TEMPEST  eauipment  radiation 
characteristics.  The  zone  includes  all  space 
within  which  a  successful  hostile  intercept  of 
compromising  emanations  is  considered  possible. 
The  Air  Force  (AFR  100-45),  the  Defense 
Communications  Agency  and  the  National  Security 
Agency  have  regulations  covering  all  phases  of 
Electronic  Security. 

For  additional  information.  Government 
employees  can  obtain  80  hours  of  traininq  at  the 
TEMPEST  Officer  Course  L30ZR301 6-006,  PDS  Code 
QVJ  conducted  at  the  USAF  Technical  Trainina 
School,  Lackland  Air  Force  Base,  Texas. 

Industry  and  Government  personnel  with  security 
clearances  can  also  attend  a  40  hour  course 
titled  "TEMPEST  Design,  Control  and  Testing" 
presented  by  Don  White  Consultants  Inc,  of 
Gainsville,  VA.  Firms  have  TEMPEST/EMI 
Departments  which  also  provide  consulting 
services.  The  Air  Force  Cryptological 
Support  Center,  San  Antonio  Texas  is  another 
source  of  information. 

The  Federal  Communication  Commission  (FCC) 
regulations  on  Electromagnetic  Interference 
provides  some  unclassified  emanation  data 
(Figure  4).  An  understanding  of  the  problem  can 
be  obtained  by  looking  at  the  EMI  test  methods 
used  by  the  FCC.  A  description  of  how  they 
satisfy  their  test  requirements  from  30MHz  to 
1000MHz  is  covered  in  an  article  by  Glen 
Dash. (19)  He  notes  that,  "Most  radiated 
emissions  arising  from  computer  equipment  stem 
from  attached  I/O  cables.  When  the  equipment 
under  test  (EUT's)  digital  logic  changes  state, 
RF  current  pulses  cause  radiation  from  pc  board 
traces  and  wires.  Because  the  attached  I/O 
cables  are  long  wires  they  are  the  most 


89 


efficient  radiators  below  100  MHz."  He  also 
notes  that  "FCC  rules,  as  now  interpeted,  permit 
computer  manufacturers  to  test  without  attached 
cables  but  require  peripheral  manuf acturers  to 
test  with  attached  cables.  And  all  I/O  cables 
must  be  driven  by  an  active  source,  such  as  a 
computer.  To  remedy  this  situation,  the  FCC 
Office  of  Science  and  Technology  is  considering 
new  regulations.  These  regulations  will  require 
the  Computer  equipment  be  tested  with  attached 
cables  and  that  the  cables  be  moved  during 
radiation  detection."  It  is  important  to  note 
that  the  FCC  is  concerned  with  EMI  emissions  and 
has  established  peak  level  emanations  (Figure  4) 
whereas  TEMPEST  concern  is  with  data  related 
emanations. 

The  National  Security  Agency  has  an 
Industrial  TEMPEST  Program.  The  Subcommittee  on 
Compromising  Emanations  (SCOCE)  has  a  TEMPEST 
Qualifications  Special  Committee  (TQSC )  which 
issues  a  Preferred  Products  List.  Accreditation 
is  given  to  those  products  that  have  fully 
complied  with  all  applicable  TEMPEST 
requirements. 

Solutions  to  satisfy  the  training/simulator/ 
computer  facility  emanations  problem  involves 
modifications  to  either  the  equipment  or  the 
facility.  It  is  important  to  identify  the 
emanation  db  and  frequency  level  before  a 
solution  is  proposed.  The  equipment  mods  could 
be  as  simple  as  using  aluminum  or  lead 
enclosures  or  tapes.  It  could  be  a  design 
change  which  does  not  significantly  increase  the 
transport  delay  time  in  equipment  performance. 

As  noted  above  the  SCOCE  has  a  Preferred 
Products  List  of  equipment  which  have  been 
tested.  Security  for  ADP  equipment  must  be  part 
of  a  facility  plan.  Possible  solutions  for  new 
or  existing  facilities  include  armor  shielded 
walls  or  very  thick  concrete  walls,  locating  the 
computers  and  other  equipment  in  the  below  grade 
basement  with  an  RF  shielded  basement  ceiling, 
fenced  enclosures  several  hundred  yards  away 
from  the  building,  separate  power  filters  for 
the  RED  &  BLack  electrical  power  lines,  signal 
filters  and  telephone  filters,  plastic  coupling 
of  all  water  pipe  lines  going  into  classified 
work  areas,  and  a  common  ground  for  all  pipes. 

If  the  classified  work  area  is  small,  an  RF 
shield  room  can  be  obtained.  At  AFHRL/OT 
Williams  AFB  we  developed  a  specification  for  an 
8  ft  x  12  ft  x  8  ft  high  modular  RF  shield  room 
which  included  comnuni cation  and  power  filters, 
assembly,  electrical  connections  and  a  test  to 
NSA  65-6  and  MIL-STD285.  On  competitive  bid  we 
obtained  this  room  for  approximately  S 1 5 , 000 
from  Lectro  Magnetics  Inc  of  Los  Angeles,  CA. 

e)  Other  Design  Features.  This  includes: 
Uninterruptable  Power  Supply  (UPS)  which  should 
not  be  confused  with  an  AC  Power  Protection 
System;  accommodations  for  the  handicapped  (20) 
in  restrooms,  dining  areas,  elevators,  at 
special  water  fountains  and  with  ramps  at 
entrance  points  which  will  enable  the 
handicapped  to  better  use  facility  services. 
Safety  features  in  accord  with  AFR  88-15  (CG) 
Section  1-38,  "Air  Force  Occupational  Safety  and 
Health  (AFOSH)  Program."  Student  or  crew 
lounges  should  be  planned  rather  than  to  have 


these  functions  in  an  unused  or  office  area. 
Secretary  or  typing  areas  should  include  sound 
absorption  material  such  as  acoustical  tile, 
rugs,  curtains  or  other  fabric  on  partitions. 
Conference  rooms  should  be  desiqned  with 
projection  booths,  speaker  equipment,  liaht 
dimmers,  acoustical  materials,  microphone  and 
telephone  outlets  for  telephone  conference 
meetings.  If  protected  information  is  to  he 
discussed  in  telephone  conferences,  then  secure 
voice  and  video  processing  equipment  with 
associated  filters  should  be  used.  Parkinq  lots 
should  be  designed  with  a  light  sensor 
controlled  night  lighting  and  special  spaces  for 
bicycles,  motorcycles,  small  cars  and  vans. 

3.  CONCLUSIONS 


A  training  or  simulator  facility  is  a 
technical  complex  that  requires  coordination  and 
integration  of  all  resources  if  it  is  to  be 
acquired  when  needed.  Good  planning  and  design 
before  it  is  built  or  modified  will  provide  a 
building  that  enhances  the  opportunities  to 
optimize  the  training  mission.  By  working  with 
the  Base  Civil  Engineer  and  MAJCOM  Civil 
Engineer,  the  major  MILESTONES  of  the  3-year 
cycle  for  processing  and  approval  of  the  DD  Form 
1391  through  the  Military  Construction  Program 
review  to  Congress  can  be  identified  and 
achieved.  Success  results  from:  1)  havinq 
accurate  and  meaningful  information  on  the  DD 
Form  1391;  2)  working  closely  from  the  start 
with  the  Base  Civil  Engineer  and  the  Architect 
Engineer;  3)  defining,  integrating  and  funding 
the  MCP,  manpower,  and  equipment  requirements  to 
accomplish  the  training  mission;  4)  planning  a 
modular  facility  that  provides  necessary  space 
for  today's  mission;  5)  having  flexible  and 
reliable  electrical  service  via  AC  Powe> 

Protection  System  and  UPS  to  handle  electrical 
abnormalities  such  as  spikes,  lightning  strikes, 
blackouts  or  brownouts;  6)  designing  air 
conditioning  for  computer  areas  to  meet 
manufacturer's  specifications  with  controlled 
comfort  zones  for  employees;  7)  providing  for 
physical  and  electronic  security,  and  81  havinq 
a  pleasant  office  and  healthy  environment  which 
includes  color,  fabrics,  rugs  and  daylight 
simulating  lights.  The  above  suggestions  are 
based  on  many  years  of  combined  facility 
engineering  experience  but  should  not  be 
considered  an  inclusive  list.  Following  these 
suggestions  will  result  in  the  timely 
acquisition  of  a  facility  that  enhances  the 
effectiveness  of  the  training  mission. 
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abstract 

Growing  emphasis  on  simulation  of  low  altitude  and  air-to-air  tactical  scenarios  has  greatly 
increased  the  requirement  for  simulator  visual  systems  capable  of  providing  the  pilot  high-fidelity 
out-of-the-cockpit  cues.  Evaluation  of  visual  System  performance  through  simulator  flying  studies  has 
been  the  primary  measure  of  system  quality.  Such  studies  can  be  costly  and  time  consuming,  and  often 
they  provide  equivocal  results.  The  present  set  of  experiments  was  conducted  to  investigate  the  use  of 
psychophysical  measurement  methodology  to  provide  a  quick,  low-cost  evaluation  of  the  altitude  cueing 
effectiveness  of  simulator  visual  displays.  Experiment  I  examined  altitude  perception  in  several 
visual  environments.  Experiment  11  was  a  validation  effort,  in  which  flying  performance  was  evaluated 
in  selected  visual  environments.  In  Experiment  I  pilots  made  altitude  estimates  based  on  static,  and 
dynamic  presentations  of  visual  displays  containing  texture  and  varying  sizes  of  j-d imens lona 1 
objects.  Best-fitting  power  functions  were  used  to  relate  perceived  altitude  to  actual  altitude,  in 
Experiment  II  Air  force  pilots  flew  the  Advanced  Simulator  for  Pilot  Training  F -16  through  five 
selected  visual  environments  at  600  kt  and  150  ft  AGl.  Reliable  difference  were  found  as  a  function  of 
display  variables^  In  environments  which  provided  strong  altitude  cues,  pilots  were  able  to  fly  very 
close  to  the  desfgnated  altitude.  In  environments  which  provided  poorer  cues,  pilots  flew 
substantially  above  designated  altitude. 


INTRODUCTION 

As  a  result  of  the  current  trend  in  flight 
simulation  toward  tactical  flight  and  combat 
scenarios,  a  need  exists  for  methodologies  to 
evaluate  the  effectiveness  of  visual  system 
displays  in  providing  out-of-the-cockpit  flight 
cues.  The  simulator  visual  system  presents  the 
pilot  with  a  variety  of  cues  needed  to  perform 
the  task.  These  range  from  airspeed,  altitude, 
and  navigation  cues  to  cues  relating  to  the 
presence,  range,  and  behavior  of  threats  and 
targets.  Simulator  flying  studies  have  been 
performed  to  determine  the  effectiveness  of 
texture  (1),  color  (2),  and  three-dimensional 
objects  (3)  in  providing  low-altitude  flight 
cues.  While  such  studies  provide  the  ultimate 
measure  of  the  effectiveness  of  a  visual  system 
display  in  providing  cues  needed  to  perform 
simulated  flight  tasks,  they  can  have  severe 
methodological  limitations.  The  requirements  of 
such  studies  for  simulator  time,  subject  time, 
and  development  time  are  great.  Simply  to  study 
the  effectiveness  of  one  type  of  visual  cue  can 
require  as  much  as  50  hours  of  simulator  time, 
even  if  only  a  small  number  of  subjects  is  run. 
Therefore,  only  a  limited  number  of  visual 
environment  displays  may  be  investigated. 

In  order  to  perform  the  parametric  studies 
required  for  the  design  of  effective  simulator 
visual  environments,  techniques  are  needed  for 
assessing  the  cueing  effectiveness  of  visual 
displays  quickly  and  at  low  cost.  Such 
techniques  might  be  used  to  screen  candidate 
displays  so  that  only  the  most  effective  need  be 
examined  in  more  comprehensive  simulator  flight 
studies. 

De  Maio  and  8rooks  (4)  nave  used  a  free 
modulus  altitude  estimation  task  to  evaluate  the 
altitude  cueing  effectiveness  of  flight 
simulator  visual  environments.  Five 
environments  were  investigated,  which  varied  in 


the  density  of  3-dimensional  objects  and  in  the 
level  of  detail  of  individual  objects.  Object 
density  was  found  to  nave  a  potent  effect  on 
altitude  perception.  The  present  set  of 
experiments  extends  the  findings  of 
De  Maio  and  Brooks  to  more  detailed  visual 
environments  and  investigates  the  relationship 
between  altitude  perception  and  flying 
performance. 

EXPERIMENT  I 

The  purpose  of  Experiment  1  was  threefold. 
The  primary  purpose  was  to  extend  the  findings 
of  De  Maio  and  Brooks  tu  a  very  nigh  object 
density  environment.  A  second  question  of 
interest  was  the  relative  effectiveness  of  other 
types  of  environmental  features  than  those  used 
by  De  Maio  and  Brooks  in  providing  altitude 
cues.  The  third  question  was  a  methodological 
one  concerning  the  procedures  used  to  evaluate 
cueing  effectiveness. 

Since  the  altitude  judgements  normally  made 
by  pilots  are  made  at  speed,  there  was  some 
question  regarding  the  appropriateness  of  tne 
assumption  underlying  the  static  altitude 
estimation  procedure  for  evaluating 
environmental  cues  which  would  be  used  in  a 
dynamic  context.  De  Maio  and  Brooks  made  the 
assumption  that  the  distribution  of  objects  in 
tne  static  display  provides  essentially  tne  same 
altitude  cue  information  as  does  the  flow  of 
objects  in  the  dynamic  display.  In  Experiment  1 
this  assumption  was  tested  by  using  both  static 
and  dynamic  presentation  modes. 


METHOD 


Subjects 


Subjects  were  cl  A -10  pilots.  None  had  had 
any  previous  experience  with  the  Advanced 
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Simulator  tor  Pilot  Training  lASPT). 

Apparatus 

Three  ASPT  visual  env i ronroe' • _  *ere  used. 
These  were  created  h  varying  the  level  of  scene 
complexity  i"  on  extant  ASPT  environment  design 
to  support  low  altitude  flight.  The  most 
complex  environment  (Cond  1)  consisted  of  a 
valley  floor  approximately  1/2  mile  wide  and 
covered  with  a  hand-modeled  texture  pattern.  On 
each  side  of  the  valley  floor  were  mountains 
approximately  4000  ft  in  height.  Inverted 
tetrahedrons  ("trees")  with  white  bases  were 
randomly  placed  on  the  floor  and  mountain  walls 
at  a  density  of  aDout  700  per  square  mile. 

These  trees  had  three  heights:  35,  50,  and  75 
feet. 

The  intermediate  complexity  condition  (Cond 
2)  consisted  of  the  same  mountains  and  textured 
valley  floor  without  the  trees.  Tne  minimal 
complexity  condition  (Cond  3)  consisted  of  only 
the  textured  valley  floor. 

Three  presentation  modes  were  used:  a 
static  slide  presentation  (SL),  a  dynamic  video 
tape  (straight  and  level  flight, 

A/S  =  450  kt)  presentation  (DT),  and  a  static 
video  tape  presentation  (ST).  Tne  ST  conditio" 
was  used  Decause  tne  image  quality  was 
substantially  poorer  in  the  video  tape  than  in 
tne  slides.  This  condition  permitted 
determination  any  decrement  which  might  nave 
been  caused  by  tne  image  quality  difference. 

Eight  altitudes  were  presented.  Altitude 
varied  between  50  ft  and  400  ft  in  equal  log 
intervals.  This  distribution  was  used  to 
provide  a  uniform  distribution  of  data  points 
for  tne  log-log  linear  fitting  procedure. 

Procedure 

Two  groups  of  subjects  were  run  in  a 
briefing  room  at  Oav is-Monthan  AFB.  Image  size 
was  seven  ft  X  seven  ft.  One  group  (N=12) 
viewed  tne  presentations  in  tne  order  Sl-DT-ST. 
Tne  second  group  saw  0T-SL-ST.  Condition  ST  was 
always  presented  last  because  it  was  not  of 
interest  in  itself  but  was  merely  a  control 
condition  to  be  used  in  the  event  that 
performance  in  condition  0T  was  substantially 
poorer  than  expected. 

Stimulus  and  interstimulus  intervals  for 
condition  SL  were  determined  by  the  cycle  time 
of  a  carousel  projector  set  for  eight  sec 
display.  Tne  video  tape  was  edited  to  provide 
6-  to  8-  sec  stimulus  intervals  and  3-  to  4-  sec 
interstimulus  intervals.  Subjects  were 
instructed  to  estimate  tne  altitude  ( AGL )  in  tne 
first  stimulus  presentation.  Subsequent 
estimations  were  to  be  made  relative  to  tne 
first.  Three  runs  of  24  trials  (three 
environments  X  eight  altitudes)  were  made 
through  each  display  condition  without  feedback. 

RESULTS 

Data  were  analyzed  by  first  converting 
actual  and  perceived  altitudes  to  logarithms.  A 
least-squares,  linear  function  was  then 
determined  for  each  subject's  data  (Kling  and 
Riggs,  1971).  Tne  slope  (b)  of  this  log-log, 
linear  function  was  taken  as  a  measure  of  the 
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Slopes  for  the  nine  display  X  complexity 
conditions  are  shown  in  Table  2.  There  was  no 
significant  effect  of  image  quality  in  the 
static  presentation  modes  (CR  =  .211,  D1FF  = 
.09).  Dynamic  presentation  lead  to  better 
altitude  perception  in  environmental  condition  3 
(CR  =  .177,  D1FF  =  .352)  but  not  in  Cond  2  (01FF 
-  .077)  nor  in  Cond  1  (D1FF  =  .064). 

Tne  question  of  the  effect  of  env i ronmenta 1 
complexity  on  altitude  perception  was  addressed 
by  three  comparisons:  1 /SL  V  2/SL,  2/DT  V  3/DT 
1/DT  V  5/DT.  None  of  these  differences  was 
significant  (CR  =  .271,  D1FF  =  .243,  .104  and 
.125  respectively). 


Table  2 

Mean  altitude  estimation  slopes 
in  experiment  I 


ENVIRONMENT 

DISPLAY 

CONDITION 

SLIDE 

DYNAMIC 

STATIC 

TAPE 

TAPE 

1 

.78 

.84 

.55 

2 

.54 

.51 

.58 

3 

.37 

.72 

.29 

DISCUSSION 


Experiment  1  was  conducted  to  answer  three 
questions.  Two  of  these  questions  (static  v 
dynamic  presentation  and  cue  equivalence)  can  be 
answered  by  examining  the  results  of  Experiment 
1  alone.  In  order  to  make  a  parametric 
evaluaton  of  the  effect  of  object  density  on 
altitude  perception  the  results  of  De  Maio  and 
Brooks  and  of  Experiment  1  need  be  examined. 

With  regard  to  the  necessity  of  dynamic 
presentation,  evaluation  of  tne  cueing 
effectiveness  of  two-dimensional  texture  does 
seem  to  require  this  presentation  mode,  but  the 
cueing  effectiveness  of  three-dimensional 
objects  can  be  evaluated  using  static 
presentation.  Apparently  observers  are  able  to 
perceive  the  distribution  of  discrete  objects  in 
the  environment  and  to  use  this  information  as 
they  do  optic  flow  information.  When 
environmental  details  are  not  discrete  but 
instead  form  a  continuous,  two-dimensional 
mosiac,  the  density  gradient  information  is  not 
accessible  to  the  observer,  and  optic  flow 
information  is  necessary  for  the  perception  of 
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altitude.  Since  the  static  presentation  mode  is 
both  simpler  and  less  expensive,  this  should  be 
the  preferred  mode  whenever  possible. 

A  limited  answer  to  the  cue  equivalence 
question  can  be  obtained  from  the  results  of 
Experiment  1.  Two-dimensional  texture  (at  least 
the  pattern  used  in  the  present  work)  can 
provide  an  effective  altitude  cue,  which  is 
enhanced  neither  by  the  addition  of  large 
three-dimensional  objects  (Cond  2)  nor  by  the 
addition  of  small  three-dimensional  objects 
(Cond  1).  A  caution  is  appropriate  at  this 
point,  however.  Since  the  texture  pattern  used 
in  the  present  work  was  hand  modeled,  it  is  by 
no  means  representative  of  texture  patterns  in 
general.  We  cannot  conclude  from  the  present 
data  that  any  texture  pattern  can  provide  an 
effective  altitude  cueing,  nor  do  we  know  what 
attributes  of  a  texture  pattern  lead  to 
effective  altitude  cueing.  A  number  of  texture 
patterns  needs  to  be  evaluated  in  order  to 
ensure  that  the  factors  contributing  to  altitude 
cueing  effectiveness  are  understood. 

To  begin  to  address  the  question  of  what 
level  of  object  density  is  adequate  for  accurate 
perception  of  altitude,  the  results  obtained  by 
Oe  Maio  and  Brooks  for  very  low  density 
environments  are  examined  along  with  the  present 
data.  Figure  1  shows  the  slope  of  the  altitude 
estimation  function  versus  object  density  in  the 
two  experiments.  Also  shown  is  a  best-fitting 
exponential  function.  This  function  is  not 
intended  to  model  the  process  of  altitude 
perception  but  only  to  serve  as  a  tool  for 
equating  the  cueing  effectiveness  of  different 
environments.  This  function  becomes  asymptotic 
at  roughly  b=.8.  It  is  generally  safe  to  assume 
that  gains  Tn  performance  are  trivial  past  the 
point  where  the  functon  is  90%  complete.  The 
90%  point  occurs  at  b=.7  or  the  equivalent  of 
about  12  to  15  objects  per  square  mile.  In 
order  to  address  the  question  of  how  much  is 
enough,  it  is  necessary  to  determine  the 
relationship  between  altitude  perception  and 
flying  performance.  A  second  experiment  was 
performed  to  address  this  question. 


Figure  1.  Altitude  estimation  slope 
vs  object  density 


EXPERIMENT  11 

The  purpose  of  Experiment  11  was  ti 
determine  the  ability  of  pilots  to  maintain 
altitude  based  on  out-of -the-cockpi t  ..ues  in 
selected  environments,  whose  altitude  cueing 
effectiveness  was  determined  above.  In  this 
regard  Experiment  11  can  be  viewed  as  a 
validation  of  the  use  of  altitude  perceptibility 
as  a  metric  for  the  ability  of  a  visual 
environment  to  support  low  altitude  flight. 

This  in-simulator  validation  can  also  be  of  use 
in  determining  what  level  of  altitude  cueing 
effectiveness  is  adequate  to  support  low  level 
f  1  ight. 

METHOD 


Subjects 

Twelve  Air  Training  Command  instructor 
pilots  at  Williams  AFB  volunteered  to  serve  as 
subjects.  Of  these,  three  were  eliminated  from 
the  analysis  due  to  unreadable  data  tapes.  None 
of  the  remaining  subjects  had  had  any  previous 
experience  with  ASPT. 

Flying  was  performed  in  the  ASPT  F -16 
simulator.  Neither  instruments  nor  Head-up 
displays  (HUD)  providing  altitude,  pitch,  bank, 
vertical  velocity  or  flight  path  angle 
information  were  available  to  the  pilot.  Five 
visual  environments  were  used.  Three  were  from 
De  Maio  and  Brooks  (Conds  D-l,  D-2,  and  D-5), 
and  two  were  from  Experiment  1  (Conds  1  and  Cond 
3).  These  five  conditions  spanned  the  range  of 
cueing  effectiveness  levels  obtained  in  the  two 
experiments. 

Procedure 

Subjects  were  given  a  15-minute  practice 
period  to  get  accustomed  to  the  F -16  simulator. 
During  this  period  they  flew  in  two  of  the  test 
environments  (Conds  D-l  and  1)  with  full 
instrumentation  but  only  airspeed  on  the  HUD. 

Subjects  flew  two  experimental  runs  through 
each  environment  with  the  cockpit  instruments 
occluded.  On  each  run  the  pilot  was  to  fly  the 
length  of  the  course  at  600  kt  and  150  ft  AGL. 

At  a  specified  point  the  pilot  performed  a 
Whif f erd ill  and  then  flew  back  to  the  start 
point  at  the  same  airspeed  and  altitude.  The 
order  in  which  subjects  flew  the  five 
environments  was  counterbalanced  to  control  for 
first  order  effects.  Altitude  AGL  was  recorded 
at  30  Hz. 

RESULTS  AND  DISCUSSION 

Data  from  the  Wi ff erd ill  portion  of  the  task 
were  omitted  from  the  present  analysis.  Only 
the  level  flight  portions  were  considered.  A 
target  altitude  was  determined  for  each  run  by 
averaging  the  local  altitude  minima  and  maxima 
on  that  run.  Mean  target  altitudes  for  each 
level  of  altitude  cueing  effectiveness  are  shown 
in  Figure  2.  When  the  dynamic  altitude 
estimation  slope  is  used  for  Cond  3,  the 
correlation  between  mean  slope  and  mean  target 
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altitude  is  -.98  (P  <  .01).  This  result 
demonstrates  the  validity  of  the  altitude 
perception  metric  for  evaluation  of  the  ability 
of  visual  displays  to  provide  the  pilot 
information  needed  to  maintain  altitude.  The 
superior  prediction  of  flying  performance 
obtained  with  the  dynamic  presentation 
evaluation  of  texture  demonstrates  the  need  for 
dynamic  evaluation  of  altitude  cueing 
effectiveness  of  this  display  feature. 

Results  of  an  analysis  of  variance  on  the 
target  altitude  data  are  shown  in  Table  3. 
Post-hoc  analysis  by  a  Ounn  test  showed  that 
Cond  D-2  was  significantly  worse  than  the 
average  of  Cond  D-l  and  Cond  1  (CR  =  17.7,  DIPT 
*  77.2,  P  <  .01).  Slopes  associated  with  this 
comparison  were  .5  and  .8,  respectively.  The 
difference  between  Cond  0-2  and  Cond  0-5  was 
non-significant 
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features  in  Cond  D-l.  It  is  likely  that  the 
difference  in  subjective  evaluation  stems  not 
from  a  difference  in  altitude  cueing 
effectiveness  but  from  differences  in  ground 
track  cueing  effectiveness.  In  order  to  specify 
completely  the  effectiveness  of  simulator  visual 
environments  in  providing  information  needed  for 
low  altitude  flight,  research  is  needed  to 
determine  what  aspects  of  the  visual  environment 
are  relevant  to  ground  track  cueing  and  how  they 
relate  to  flying  performance. 

CONCLUSIONS 

1.  Altitude  perceptibility  (slope  of  the 
altitude  estimation  function)  is  a  valid  metric 
of  the  ability  of  a  simulator  visual  display 
environment  to  provide  a  pilot  information 
needed  to  maintain  altitude  in  low  level 
flight.  When  an  environment  containing 
three-dimensional  objects  is  evaluated,  static 
presentation  may  be  employed.  Evaluation  of  the 
cueing  effectiveness  of  two-dimensional  texture 
requires  a  dynamic  presentation  mode. 

2.  A  potent  cue  for  altitude  perception  comes 
from  the  distribution,  or  flow,  of  environmental 
features. 


Figure  2.  Target  altitude  vs  altitude 
estimation  slope 

( D1FF  =  51.8).  Associated  slopes  were  .5  and 
.2.  Differences  between  Conds  1  and  D-l  and 
between  Conds  1  and  3  were  also  non-significant 
(D1FF  =  12.5  and  7.7,  respectively).  These 
results  support  the  previous  conclusion  that  an 
environment  giving  an  altitude  estimaton  slope 
of  about  .7  is  necessary  and  sufficient  to 
support  maintenance  of  altitude  in  low  altitude 
flight. 

Table  3 

Results  of  one-way  ANOVA  performed 
on  target  altitudes  in  five  visual 
display  environments 

SOURCE _ MEAN  SQUARE  0.  F,  F-RATiO  p 

TOTAL  5100.49  44 

ENVIRONMENT  29194.05  4  13.65  .001 

ERROR _ 2138.35 _ 32 _ - 


There  is  one  difficulty  with  the  conclusions 
presented  above.  That  is  pilots  report  Cond  1 
to  te  much  easier  to  fly  in  than  Cond  D-l  even 
though  they  maintain  altitude  no  better.  The 
reason  for  this  seeming  discrepancy  can  be  seen 
in  Figure  3.  Figure  3  shows  examples  of 
subjects'  ground  track  in  the  two  environments. 
It  can  be  seen  that  ground  track  variability  is 
much  higher  in  Cond  D-l  than  in  Cond  1.  This 
difference  results  from  the  lack  of  distinctive 


Figure  3.  Examples  of  ground  tracks, 
Cond  1  is  shown  in  3a  and  3b, 

Cond  D-l  is  shown  in  3c  and  3d 

Perception  of  this  information  improves  as  the 
density  of  features  in  the  visual  environment 
increases.  For  three-dimensional  objects  a 
density  of  about  12  to  15  objects  per  square 


mile  is  necessary  and  sufficient  for  maintaining 
of  altitude.  Equivalent  cueing  effectiveness 
(b  =  .7)  can  be  provided  by  a  two-dimensional 
texture  pattern.  A  weak  altitude  cue  is  also 
provided  by  information  about  the  aspect  of 
individual  objects,  but  the  effectiveness  of 
this  cue  is  poor  compared  to  that  of 
gradient/flow  cues. 

3.  A  second  aspect  of  visual  cueing 
effectiveness  was  identified  having  to  do  with 
ground  track  control.  This  aspect  of  aircraft 
control  involves  initiation  and  control  of 
turns.  Visual  cues  required  for  ground  track 
control  are  those  which  permit  identification  of 
roll-in  and  roll-out  points.  Unlike  altitude 
cues,  which  must  be  uniformly  distributed 
throughout  the  environment,  ground  track  cues 
must  be  placed  around  particular  decision 
points.  A  complete  evaluation  of  the  ability  of 
a  visual  environment  to  support  low  level  flight 
requires  measurement  of  its  ability  to  provide 
both  altitude  related  information  and 
ground-track  related  information. 
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ABSTRACT 

The  DMA  data  base  and  its  future  enhancements  have  been  hailed  as  the  general 

solution  to  creating  visual  data  bases  for  CIG.  DMA  centered  approaches  have  proven 
marginal  or  ineffective,  however,  in  providing  visual  support  of  low  altitude  flight, 
since  DMA  stresses  navigation  rather  than  flying  skills. 

The  imagery  presented  by  the  CIG  system  must  tell  the  pilot  where  he  is  relative  to 
his  map,  and  where  he  is  relative  to  the  ground.  These  are  two  very  different  objectives, 

and  emphasizing  one  may  compromise  the  other.  Heavy  emphasis  on  capture  criteria  (for 

map  fidelity)  has  historically  resulted  in  systems  which  do  an  inadequate  job  of 

supporting  low  level  flight,  a  task  which  depends  on  high  scene  density'.  This  paper 
examines  the  capture  criteria  and  scene  densities  required  to  support  such  missions,  and 
quantifies  critical  aspects  of  a  nap  of  earth  data  base.  We  will  examine  various 
constraints  inherent  in  CIG  systems,  and  their  influence  on  what  can  be  achieved.  We  also 
will  discuss  data  base  definition  strategies,  including  the  use  of  DMA  data,  to  see  where 
traditional  approaches  have  been  deficient  in  providing  the  required  visual  cues.  Then  we 
will  present  an  approach  which  combines  DMA  data,  new  mathematical  methodologies  and  data 
base  design  strategies,  and  current  production  hardware,  to  meet  both  the  capture  criteria 
and  scene  density  needs  of  'nap  of  earth'  missions. 


INTRODUCTION 

Whole  mission  simulation  is  a  multifaceted 
technological  challenge.  The  total  integration  of 
instrument,  radar,  sensor  and  visual 
reinforcement  requires  the  mastery  of  a  variety 
of  technical  disciplines.  The  task  is  made  even 
more  demanding  because  the  processes  which  create 
and  support  various  aspects  of  the  simulation  are 
becoming  ever  more  complex  and  disparate,  while 
the  need  to  correlate  these  aspects  gets  steadily 
stronger. 

Computer  generated  visual  imagery  is  one  of 
the  most  demanding  of  these  facets.  Visual 
imagery  must  correlate  with  and  reinforce 
information  being  received  from  other  sources, 
including  radar,  infrared  and  radio  navigation 
systems.  It  must  support  those  aspects  of  flight 
navigation  which  are  based  on  looking  out  the 
window:  general  topography,  major  terrain 

characteristics  and  significant  cultural  features 
which  serve  as  navigational  waypoints  must  be 
recognizable  and  correctable  with  other 
navigation  processes.  Finally,  the  visual  imagery 
must  support  flight  skills  by  conveying  to  the 
pilot  an  accurate  sense  of  spatial  and  dynamic 
relationships.  Users  are  requiring  these 
capabilities  to  be  achieved  with  increasing 
effectiveness  in  ever  larger  and  more  complex 
visual  environment  data  bases.  DMA  data  has  been 
increasingly  relied  on  to  provide  the  real  world 
and  radar  correlations  required  in  such  systems. 

THE  DMA  CONTRIBUTION 

The  Defense  Mapping  Agency  Digital  Terrain 
Data  Base  proceeds  from,  and  is  designed  to 
efficiently  support,  radar  driven  navigational 
needs.  The  DMA  data  source  provides  two  basic 
categories  of  information  in  the  form  of  terrain 
files  and  culture  files.' 11  The  terrain 
files  contain  terrain  elevation  values,  in 
meters,  corresponding  to  sample  points  along  a 
regular  grid  in  latitude  and  longitude. 
Currently,  terrain  files  are  available  in  two 


levels  of  sample  spacing.  Level  1  and  Level  2. 
The  latitude  spacing  of  the  grid  is  3  arc-seconds 
for  Level  1  and  1  arc-second  for  Level  2,  while 
the  longitude  spacing  varies  from  3  to  18 
arc-seconds  (Level  1)  or  from  1  to  6  arc-seconds 
(Level  2),  in  order  to  keep  the  grid 

approximately  square.  The  absolute  accuracy 
requirements  for  terrain  data  are  specified  as 

130  meters  horizontally  and  ±30  meters  vertically 
for  both  Level  1  and  Level  2. 

Culture  files  are  also  available  in  two 

levels  of  detail:  Level  1,  which  provides  a 

generalized  description  and  portrayal  of 
planimetric  features  which  meet  relatively  large 
minimum  size  requirements;  and  Level  2,  which 
provides  a  more  detailed  description  and 
portrayal  of  features  which  meet  somewhat  smaller 
minimum  size  requirements.  The  absolute  accuracy 
requirement  for  culture  file  data  is  130  meters 
for  Level  1  data,  and  2G  meters,  point  to  point, 
for  Level  2  data,  with  the  additional  constraint 
that  Level  1  and  Level  2  feature  detail  must  be 
compatible.  Vertical  accuracy  specifitations 
apply  only  to  vertical  obstructions  of  46  meters 
or  greater,  and  an  accuracy  of  ±10  meters  is 
specified  for  such  features. 

DMA  AND  NAVIGATIONAL  CUES 

The  essential  role  of  navigation  cues  in  a 
visual  data  base  is  that  of  guiding  the  pilot 
along  a  course  marked  by  a  sequence  of 
recognizable  milestones,  from  a  point  of  origin 
to  a  destination.  The  cues  which  are  ultimately 
used  will  depend  largely  on  the  type  of  mission 
to  be  supported,  the  flight  altitude  domains,  the 
strategic  or  tactical  nature  of  the  task  and  the 
characteristics  of  the  terrain  being  overflown. 
Features  which  can  be  important  navigational  cues 
in  an  expansive  desert  landscape  can  be  totally 
insignificant  in  a  highly  forested,  hilly 
terrain.  A  segment  of  terrain  designed  to  support 
high  altitude  navigation  may  not  require  the 
density  of  cues  needed  to  support  navigation  at 
lower  altitudes.  Navigational  needs  will  often  be 
different  in  one  portion  of  the  data  base  than  in 
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others.  The  data  base  designer  may  capitalize  on 
such  differences  in  order  to  concentrate 
navigational  cues  where  they  are  most 
significant. 

The  required  spatial  frequency  of  navigation 
cues  tends  to  be  relatively  low  at  all  altitudes. 
In  real  world  missions  the  frequency  of 
navigational  waypoints  is  dictated  by  pilot 
workload  constraints,  and  tends  to  be  determined 
by  flight  time  intervals  of  between  15  and  60 
seconds.  For  tactical  missions  involving  high 
speed  low  altitude  flight,  the  spatial 

distribution  of  specific  navigational  features 
can  be  quite  sparse  while  still  providing  an 
excess  of  waypoints  which  can  be  used  during  the 
mission. 

The  DMA  terrain  elevation  data  provides  a 
natural  starting  point  for  the  definition  of 

large  scale  terrain  topography  for  both  the 
visual  and  radar  simulations.  A  variety  of 
approaches  have  been  used  to  transform  the  data, 
correct  errors  or  inconsistencies,  and  convert  it 
to  forms  displayable  by  computer  image 
generators.  The  nature  and  scale  of  the  data 

provide  sufficient  correlation  to  fulfill 
navigational  needs  of  the  visual  environment. 
However,  a  preliminary  analysis  of  the  cultural 
files  suggests  that  much  of  the  wealth  of  data 
contained  in  these  manuscripts  is  not  designed  to 
support  the  visual  data  base  design  task,  nor 
provide  effective  imagery  for  'nap  of  earth'  or 

low  altitude  flight.  Positional  information, 
dimensions,  material  descriptions  and  coverage 
factors  are  potentially  useful  in  providing 
cultural  navigational  cues  and  generic  terrain 
embellishment  for  optical  flow,  however. 

OPTICAL  FLOW  AND  LOW  LEVEL  FLIGHT 

At  high  altitudes  there  is  little  danger  of 
crashing  into  the  ground,  and  ground  topography 
is  of  interest  primarily  to  support  navigational 
goals.  In  flight  profiles  very  close  to  the 
ground,  however,  a  high  percentage  of  visual  cues 
must  be  designed  to  support  terrain  avoidance  and 
flying  skills  such  as  those  employed  to 
stealthily  approach  targets  without  being 
detected  by  potential  threats.  The  lower  a  pilot 
tries  to  fly,  the  more  he  depends  on  key 
characteristics  of  the  visual  scene  in  front  of 
him.  His  attention  gradually  shifts  from  cockpit 
data  sources  to  the  outside  world;  as  his  work 
load  increases  he  must  extract  from  the  visual 
scene  better  information  at  faster  rates  in  order 
to  avoid  impact  with  the  terrain.  This  ability 
depends  on  a  complex  set  of  visual  factors, 
including  the  optical  streaming  of  scene  details 
away  from  a  single  fixed  image  point  (the  "aim 
point"),  the  rate  of  motion  of  image  details, 
relative  parallax  shifts,  and  the  emergence  of 
successive  levels  of  detail  (including  any 
absolute  size  cues) . 

Some  work  has  been  done  in  attempting  to 
quantify  these  factors  and  transfer  therr  into  a 
computer  generated  visual  scene.  Early  attempts 
at  providing  these  cues  with  abstract  repetitive 
surface  texture  (i.e.  checkerboards)  were 
comparatively  unsuccessful.  Once  pilots  had 
calibrated  the  texture  to  determine  how  many 
wavelengths  above  it  they  should  fly,  holding  a 
constant  height  above  terrain  was  very  easy.  Such 


training  does  not  transfer  well  to  the  real 
world,  since  it  is  based  on  strong  artificial 
cues  which  may  be  absent  in  the  actual  mission. 
More  recent  research12’  has  suggested  that 
a  mixture  of  surface  texture  and  three 
dimensional  features  is  required,  and  that  these 
cues  should  be  distributed  throughout  the  image 
plane  so  that  a  certain  density  of  cues  per  solid 
angle  is  maintained.  This  last  requirement  ties 
the  spatial  density  of  cues  to  the  minimum  flight 
altitude,  and  suggests  some  simple  rules  for 

computing  this  density. 

NATURE  AND  DENSITY  OF  NOE  FLIGHT  CUES 

John  Sinacori,  as  quoted  from  reference  2 
above,  suggests  that  "the  dominant  perceptual 
strategy  used  for  NOE  point  to  point  flight  is 

motion  perspective  (optical  flow)  augmented  by 
other  mechanisms,  such  as  linear  and  aerial 
perspective,  interposition,  shading,  texture  and 
apparent/familiar  size,  if  and  when  their 
corresponding  stimuli  are  available."  He 
establishes  a  suggested  minimum  distribution  of 
textural  elements  in  the  visual  scene  which  is 
quantitatively  related  to  the  mean  height  of  the 
pilots  eye  above  the  ground  surface.  He  suggests 
that  appropriate  stimuli  to  support  the  motion 
perspective  perceptual  strategy  should  consist  of 
a  random  distribution  of  textural  elements  of 
varying  size,  shape  and  contrast,  whose  mean 
spacing  is  approximately  one  eye  height.  He 

cautions  that  the  estimate  is  preliminary  and 

emphasises  that  such  an  element  spacing  is  deemed 
a  minimum  texture  level  needed  to  reveal  surface 
shape  using  motion  perspective.  He  further  states 
that  although  regular  patterns  or  highly  coherent 
texture  may  reduce  pilot  workload  they  should  be 
avoided.  Such  regular  patterns  as  checker  boards 
invite  the  prospect  of  learned  responses  and 
negative  training. 

Within  the  framework  of  the  motion 
perspective  (optical  flow)  mechanism,  additional 
strategies  suggest  themselves  which  relate  to 
other  perceptual  mechanisms  in  both  a 
complementary  and  a  supplementary  role.  Sinacori 
states  that  "what  should  reduce  workload  and/or 
improve  performance  is  the  addition  of  coherent 
objects  that  more  easily  facilitate  a  static 
perception  of  terrain  surface  shape  and  observer 
position  relative  to  that  surface."  He  further 
asserts  that  "The  addition  of  vertical  objects 
should  also  reduce  workload  and/or  improve  height 
holding  performance",  and  suggests  a  mean 

separation  of  vertical  objects  of  about  three  to 

five  eye  heights.  The  inclusion  of  3D  objects 
such  as  trees,  bushes  and  rocks,  in  addition  to 
contributing  optical  flow  cues,  provides  parallax 
cues  and  information  about  relative  sizes  of 

known  objects  which  can  be  particularly  valuable 
at  slower  speeds  or  when  performing  hover 
operations. 

Sinacori  provides  a  specific  example  of  an 

NOE  data  base  designed  around  the  preceedmg 
notions.  He  uses  a  portion  of  the  Fort  Hunter  - 
Liggett  area  to  postulate  a  helicopter  NOE 
mission  near  the  Nacimiento  valley.  Adequate 
ground  truth  is  achieved  with  about  1000  polygons 
per  square  kilometer  (this  density  roughly 
corresponds  with  direct  skinning  of  the  DMA 
terrain  elevation  grid).  A  dense  2D  polygonal 
enhancement  is  added  to  the  terrain  to  further 
define  surface  shape  and  provide  optical  flow, 
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and  3D  enhancements  (trees)  are  added  at  a 
density  of  between  6000  and  12000  trees  (roughly 
100000  polygons  or  300000  edges)  per  square 
kilometer. 

IMAGE  GENERATOR  ISSUES 

The  above  example  suggests  strongly  why 
historical  attempts  to  simulate  NOE  imagery  have 
proven  inadequate.  The  typical  design  strategy 
has  been  to  convert  the  DMA  terrain  elevation 
data  set  into  a  terrain  skin  by  a  straightforward 
linear  process  which  results  in  a  similarly  sized 
output  data  set;  the  terrain  is  then  further 
embellished  with  cultural  and  organic  features  to 
provide  optical  flow  and  navigational  cues.  With 
this  strategy,  the  basic  problem  is  how  to 
produce,  store,  read,  manage  and  display  the 
resulting  very  large  data  base.  The  gulf 
between  current  capabilities  and  such  a  system  is 
measured  in  orders  of  magnitude,  not  small 
incremental  improvements.  The  following  general 
discussion  of  these  problems  acknowledges  that 
all  existing  CIG  systems  have  analogous 
limitations. 

Data  Base  Size 

A  rough  metric  of  data  base  size  would  be  to 
express  the  production  and  storage  requirements 
in  terms  of  bytes  per  polygon  (or  face).  This 
metric  would  include  the  overhead  of  data  base 
management  structures,  all  raw  geometric 
information,  and  topological  information  required 
to  assemble  the  scene.  A  value  of  200  bytes  per 
face  is  close  enough  for  our  analysis.  Referring 
back  to  Sinacori’s  NOE  example,  a  modest  25  by  25 
kilometer  data  base  would  require  roughly  13 
Gigabytes  of  information.  A  large  area  tactical 
data  base  of  several  hundred  thousand  square 
kilometers  modeled  to  a  density  of  100000 
polygons  per  square  kilometer  would  be 
prohibitively  expensive  to  produce,  and  would 
require  hundreds  of  very  large  disks  to  store. 

Disk  Bandwidth  and  IG  Memory 

There  is  a  direct  relationship  between  data 
base  density,  aircraft  velocity  and  the  amount  of 
data  that  must  travel  between  the  on-line  (disk 
resident)  data  base  and  the  IG  memories  each 
second.  If  the  sample  data  base  has  to  support 
speeds  of  100  knots  and  a  general  visibility  of 
two  kilometers,  then  about  four  Megabytes  of 
information  would  be  moving  from  the  disk  to  the 
IG  each  second.  The  amount  of  IG  memory  required 
to  contain  all  scene  details  within  this 
visibility  limit  would  be  nearly  250  Megabytes. 

Data  Base  Management 

The  image  generator  must  select  from  the 
entire  data  base  two  very  important  subsets  of 
data.  The  first  is  that  portion  which  must  reside 
in  IG  memory  because  it  is  closer  to  the  viewer 
than  the  system  visibility  limit.  This  subset  is 
continually  changing  as  the  simulated  aircraft 
moves  within  the  overall  gaming  area,  but  will 
generally  represent  a  small  fraction  of  the  total 
data  base.  The  rate  at  which  this  subset  changes 
may  be  comparatively  low,  so  this  task  is 
typically  performed  as  a  background  task  over 
multiple  field  times  in  the  general  purpose 
computer  which  hosts  the  disk.  The  amount  of  work 
required  to  perform  this  cull  is  related  to  total 


data  base  content.  Processes  which  are  adequate 
for  typical  production  data  bases  whose  densities 
are  10  to  100  polygons  per  square  kilometer  will 
be  inadequate  for  the  sample  NOE  problem. 

Culling  and  Display 

From  this  data  an  even  smaller  subset  is 
extracted  which  consists  of  scene  details  which 
may  be  within  the  display  windows.  This  second 
subset  is  usually  culled  to  include  only  the 
simplest  permissible  representations  of  scene 
elements  (level  of  detail  selection),  and  only 
those  surfaces  which  are  front  faced  and  large 
enough  to  be  useful  in  the  displayed  image.  The 
second  cull  processes  only  the  data  which 
survives  the  first  cull  (and  resides  in  the  IG), 
but  it  must  be  performed  once  every  field,  and  on 
a  much  richer  and  larger  set  of  image  elements. 
The  IG  must  extract  those  scene  elements  which 
are  maximally  useful  to  the  viewer,  while 
rejecting  many  others,  and  while  preventing  the 
artifacts  of  this  management  from  distracting  the 
viewer. 

SOME  HELPFUL  OBSERVATIONS 

All  of  the  above  might  suggest  a  very  bleak 
outlook  for  those  simulator  users  requiring  an 
effective  NOE  capability.  Incremental  linear 
advances  in  CIG  technology  are  not  likely  to 
catch  up  to  these  needs  as  fast  as  the  needs  are 
evolving.  What  is  required  is  a  different  way  of 
looking  at  the  problem,  and  a  totally  different 
strategy  for  dealing  with  the  requirements. 
Fortunately,  some  helpful  observations  spring  to 
mind. 

First,  there  are  two  fundamentally  different 
types  of  scene  detail  to  deal  with .  Optical  flow 
to  support  flight  skills  is  almost  entirely 
supplied  by  dense  generic  details  with  a  high 
spatial  frequency  content,  while  the  navigational 
"specificness"  of  the  data  base  is  due  to  very 
low  frequency  characteristics  of  the  terrain 
topography  and  related  cultural  cues.  This 
suggests  that  we  ought  to  try  to  discover  ways  to 
"re-use"  optical  flow  related  scene  details,  so 
that  many  visual  representations  can  be  drawn 
from  a  small  number  of  actual  elements.  We  must 
then  find  a  way  of  combining  these  reusable 
optical  flow  details  with  a  terrain  underlayment 
which  is  specific  enough  to  meet  our  navigational 
requirements. 

Second,  perhaps  we  can  discover  a  data  base 
management  strategy  that  implements  level  of 
detail  selection  while  also  providing  for  the 
physical  subdivision  of  geographic  data  base 
areas  into  smaller  areas.  This  would  give  us  a 
way  to  manage  the  data  base  so  that  rejection  of 
unneeded  scene  detail  occurs  in  pieces  as  large 
as  possible,  expediting  the  data  base  culling 
process. 

CT5:  EXPLORING  PARTIAL  SOLUTIONS 

The  Evans  and  Sutherland  CT5  image 
generator  marked  a  number  of  significant 
departures  from  historical  practice  in  the  CIG 
field.  Primary  among  these  was  the  processing  of 
image  details  by  area  rather  than  scan 
line,0’  and  the  implementation  of  all  data 
base  management  functions  in  the  IG 
hardware.'*’  Each  of  these  notions  brought 
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fundamental  changes  to  the  character  and 
capability  of  the  image  generator.  The  rigorous 
application  of  antialiasing  technology  in  the 
Display  Processor  achieved  new  levels  of  image 
quality,  while  increased  basic  capacity 
throughout  the  IG  was  augmented  by  much  more 
efficient  data  base  management.  These 

improvements  were  accompanied  by  a  better  than 
linear  capacity  response  of  the  system  in  areas 
where  NIogN  or  N-squared  responses  were  the  rule 
in  previous  systems. 

A  Hierarchical  Data  Base  Structure 

The  decision  to  implement  the  data  base 
management  function  as  a  hierarchical  tree  was 
largely  driven  by  the  need  to  sort  scene  details 
in  a  front  to  back  order.  A  powerful  extension  of 
list  priority  techniques,  Cellular  Priority,  was 
developed  to  address  the  CT5  sorting  problem.  Its 
key  property  was  the  hierarchical  subdivision  of 
the  overall  data  base  priority  problem  into  a 
tree  of  many  nested  simple  problems.  Within  such 
a  process  visibility  decisions  about  major  data 
base  elements  propagate  automatically  to  smaller 
elements.  A  similar  property  attends  the  data 
base  management  and  culling  process.  Some  key 
ingredients  of  this  structure  are  particularly 
important  to  the  NOE  data  base  management 
problem. 

A  cell  is  a  volume  in  model  space 

represented  by  a  decision  node  in  the  data  base 
tree.  The  primary  function  of  the  cell  is  to 
provide  a  choice  between  either  a  simple  or  a 
complex  representation  of  some  portion  of  the 
data  base,  based  on  the  distance  between  the  cell 
and  the  viewer.  Either  choice  can  consist  of  a 
null  (the  item  is  so  far  away  that  nothing  need 
be  displayed),  an  object  (a  collection  of 

polygons  and  light  strings),  or  a  mesh.  A  mesh  is 
a  collection  of  cells  with  a  rule  for  their 
visual  ordering.  The  mesh  is  thus  the  primary 

structure  in  the  cellular  priority  process.  The 
mesh  can  also  be  used  to  subdivide  a  region  of 
model  space  into  several  smaller  regions;  this  is 
the  primary  mechanism  used  to  control  the  degree 
of  detail  that  will  be  unfolded  before  display  or 
rejection  of  data  base  elements. 

The  data  base  tree  is  the  structure  of 

meshes  and  objects  organized  by  their  association 
into  cells;  it  is  processed,  by  testing  cells  and 
ordering  meshes.  Processing  ceases  along  any 
subpath  in  the  tree  when  the  cell  choice 
indicates  either  an  object  or  a  null.  Processing 
will  continue  when  the  cell  choice  indicates  a 
mesh.  The  order  of  processing  in  the  tree  is 
determined  by  the  ordering  rules  contained  in 
each  mesh.  At  every  stage  of  processing  the  IG 
attempts  to  prove  that  the  item  being  processed 
is  unneeded  because  it  does  not  appear  in  any 
display  window.  The  rejection  of  an  item  means 
the  termination  of  processing  along  that  subpath 
in  the  tree;  unneeded  portions  of  the  data  base 
tree  are  thus  pruned  off  as  early  in  the  process 
as  possible. 

Capacity  of  the  Object  Manager 

Processing  of  the  data  base  tree  occurs  in 
the  object  manager  (OM),  The  major  task  of  the  OM 
is  to  reject  as  much  of  the  data  base  as 
possible,  as  soon  as  possible,  and  in  pieces  as 


large  as  possible.  As  the  overall  content  of  the 
data  base  increases,  so  does  the  content  of  the 
pieces  which  will  be  tested,  and  in  many  cases 
subsequently  rejected.  Each  additional  level  of 
data  base  tree  structure  exacts  a  fixed  amount  of 
processing  time,  while  increasing  the  total  data 
base  content  by  a  multiplicative  factor.  Tree 
trace  processing  time  thus  grows  linearly  with 
data  base  depth,  and  logarithmically  with  total 
data  base  content. 

Instancing  in  the  IG 

The  CT5  image  generator  supports  the  reusing 
of  data  base  items  in  a  general  and  extensive 
fashion.  A  mesh  or  an  object  can  be  referenced 
from  multiple  cells  in  a  data  base,  and  each 
reference  can  include  a  positioning  vector  to 
plant  the  mesh  or  object  in  a  particular  place. 
All  data  base  structure  and  scene  detail  which 
ultimately  results  from  an  instance  will  also  be 
moved  to  the  new  location.  By  cascading  levels  of 
instanced  meshes,  very  extensive  and  complex  data 
base  structures  can  be  quickly  created.  For 
example,  an  entire  forest  can  be  built  from  a 
single  IG  resident  tree  and  a  very  compact  nested 
and  instanced  mesh  structure.  This  allows  a 
nearly  total  decoupling  of  memory  requirements 
from  apparent  displayed  density,  and 
significantly  reduces  the  amount  of  data  which 
must  be  transferred  from  the  disk. 

Pagjng  from  Disk  to  IG 

The  object  manager  traces  the  data  base  tree 
to  identify  data  blocks  which  may  be  needed  to 
draw  the  image,  but  which  are  not  currently  in  IG 
memory.  This  is  done  as  a  background  task  over 
several  field  times.  The  pager  algorithm  performs 
memory  block  allocation  and  garbage  collection  as 
well,  and  communicates  data  block  requests  to  the 
general  purpose  computer.  Data  transfers  from  the 
disk  to  the  IG  occur  by  direct  memory  access.  The 
hierarchical  data  structures  which  support  data 
base  management  within  the  IG  also  suffice  to 
control  disk  to  IG  processes;  no  secondary 
software  management  structures  or  tables  are 
needed.  This  process  can  support  a  very  high  rate 
of  continuous  data  flow  from  the  disk  to  the  IG. 

CT5A :  THE  NEXT  STEP 

The  CT5A  system  was  the  logical  outgrowth  of 
a  characterization  study  of  CT5.  This  study 
resulted  in  a  better  understanding  of  the  data 
base  management  problem  and  how  CT5  solves  it, 
identified  major  new  data  base  design  and 
development  strategies,  and  proposed  a  set  of 
system  modifications  to  significantly  increase 
basic  capacities  while  effectively  supporting  the 
new  modeling  approaches. ' 5 ’  These  new 
features  significantly  improve  the  ability  of  the 
system  to  address  the  NOE  simulation  problem  by 
allowing  visual  data  bases  of  over  500000 
polygons  per  square  kilometer  to  be  processed,  as 
the  following  discussion  will  illustrate. 

Fade^  Level  of  Detail 

Fade  level  of  detail  helps  mask  the  switch 
between  two  levels  of  detail  by  fading  the 
retiring  scene  element  out  as  the  replacement 
element  is  faded  in.  The  transparency  capability 
of  the  system  is  used  to  effect  the  switch,  which 
is  based  on  range  and  can  occur  at  several 
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selectable  rates.  This  greatly  reduces  the  visual 
distractions  associated  with  level  of  detail 
switching,  and  allows  these  transitions  to  occur 
much  closer  to  the  viewer.  This  helps  the  system 
concentrate  on  processing  details  which  are  large 
enough  to  be  valuable  to  the  viewer,  and 
significantly  increases  the  apparent  richness  and 
complexity  of  the  image. 

Using  Multiple  Levels  of  Detail 

In  a  visual  scene.  the  most  complex 
representation  of  an  image  detail  will  only  need 
to  be  presented  when  the  viewer  is  very  close  to 
it.  At  larger  distances  a  much  simpler 
representation  is  adequate  and  at  still  larger 
distances  only  the  proper  suggestion  of  bulk, 
shape  and  color  is  needed.  In  an  extensive  evenly 
distributed  array  of  such  details,  most  of  them 
can  be  displayed  using  the  simplest  version.  For 
a  constant  number  of  on  screen  polygons,  the 
geographic  density  of  such  an  array  can  be  much 
higher  if  multiple  representations  are  employed. 
Additional  leverage  is  obtained  by  using  fade 
level  of  detail  to  further  shorten  the  transition 
distances. 

Using  Multiple  Levels  of  Scale 

In  order  to  provide  usable  cues  over  a  range 
of  flight  altitudes  the  data  base  must  contain  a 
selection  of  cue  details  of  varying  sizes  and 
spacings.  At  close  ranges  the  smaller  cues  will 
provide  the  bulk  of  near  scene  detail;  at  longer 
ranges  the  small  cues  will  have  been  managed  out 
of  the  scene,  and  the  larger  cues  will  be  needed. 
One  result  of  this  strategy  is  that  the  angular 
distribution  of  cues  in  the  observers  field  of 
view  is  nearly  homogenous  throughout  the  image, 
instead  of  being  severely  compressed  against  the 
horizon. 


A  Mathematical  Design  Methodology 

A  rigorous  mathematical  process  can  be  used 
to  design  such  a  data  base.  The  mission  flight 
profile  is  used  to  establish  the  number  and  types 
of  levels  of  scale,  and  the  density  requirements 
of  each  level.  Components  of  the  data  base  are 
then  identified  and  characterized  as  to  number 
and  complexity  of  levels  of  detail.  Level  of 
detail  transition  strategies  are  defined,  taking 
advantage  of  factors  which  can  help  minimize  IG 
load.  A  global  instancing  strategy  is  developed 
to  separate  reusable  generic  scene  features  from 
specific  details,  and  minimize  the  total  modeling 
effort.  The  interaction  of  each  data  base  portion 
is  analyzed,  and  a  composite  IG  load  level  is 
computed.  The  data  base  development  can  then 
proceed,  confident  that  mission  visual 
requirements  will  be  met  without  overloading  the 
system. 

THE  BASIS  SET  NOTION 

The  pursuit  of  structured  and  modular  data 
base  development  strategies  grew  out  of  a  desire 
to  decouple  the  data  base  development  cost  from 
the  geographic  extent  and  total  content  of  the 
data  base.  A  first  step  in  this  direction  was  to 
separate  the  problem  into  two  distinct  portions: 
the  specific  terrain  underlayment,  and  a  reusable 
set  of  organic  and  cultural  2D  and  3D  components 
which  could  be  used  to  embellish  this  base 


terrain.  The  actual  ornamentation  of  the  terrain 
would  add  those  specific  features  which  are 
navigationally  important,  and  additional  generic 
enhancements  to  increase  realism  and  optical 
flow. 

Lineal  features  such  as  roads  and  rivers 
presented  an  interesting  problem.  They  had  to  be 
visually  continuous  across  terrain  boundaries, 
while  adhering  to  the  topological  properties  of 
the  terrain  underlayment.  A  process  for  providing 
these  features  was  developed  which  represented 
roads  by  instancing  predefined  road  segments. 
These  segments  were  modeled  in  a  set  of  road 
types,  segment  lengths,  and  segment  orientations. 
From  a  comparatively  small  set  of  these  elements 
specific,  if  somewhat  stylized,  roads  can  be 
built. 

Three  dimensional  specific  terrain  presented 
a  still  more  difficult  problem.  The  fundamental 
elements  of  a  strategy  were  identified  during  the 
course  of  extensive  experiments  aimed  at  the  NOE 
problem.  What  ultimately  emerged  was  the  concept 
of  a  basis  set:  a  set  of  scene  components  which 
exhaustively  satisfy  a  class  of  local  boundary 
conditions.  We  developed  methods  for  identifying 
and  defining  a  terrain  basis  set  from  a  given  set 
of  constraints  and  fidelity  requirements. 
Algorithmic  ways  of  choosing  terrain  basis  set 
elements  to  provide  required  specificness  were 
explored,  and  basis  sets  with  comparatively  few 
elements  were  found  to  provide  adequate  ground 
truth  and  topographic  complexity. 

USING  TERRAIN  BASIS  SETS 

A  terrain  basis  set  consists  of  a  number  of 
patches  of  terrain  which  can  be  made  to  fit 

together  in  various  ways  by  translating  each 
element  with  respect  to  its  neighbors.  In  the 
general  case,  basis  set  elements  need  not  be 
either  planar  or  similarly  shaped,  but  the 
selection  process  must  ensure  that  adjacent 
patches  have  compatible  properties  along  their 
shared  boundary.  Because  each  patch  can  be  offset 
in  Z  as  well  as  X  and  Y,  terrain  features  much 
larger  than  any  one  patch  are  easily  created;  the 
degree  of  fidelity  preserved  in  this  process 

depends  on  how  large  the  basis  patches  are 
relative  to  the  topographic  features  of  the 

terrain.  Many  algorithms  for  skinning  real 
terrain  with  a  basis  set  are  possible;  DMA 
terrain  elevation  data  provides  one  particularly 
good  starting  point. 

Each  terrain  patch  can  be  thought  of  as  a 
place  holder  in  the  terrain  skin.  Its  visual 

representation  can  be  a  simple  polygon,  or  a 
complex  scene  component  with  embedded  level  of 
detail  and  dense  3D  embellishment.  The  patch  can 
provide  additional  subdivision  of  the  terrain 
surface  to  increase  scene  complexity,  although 
this  additional  complexity  will  be  generic  in 
nature.  The  basis  set  can  include  terrain  patches 
with  various  lineal  features,  such  as  roads  and 
rivers  modeled  at  various  orientations.  Specific 
2D  and  3D  features  can  be  associated  with  the 
instance  of  a  patch  to  provide  navigationally 
specific  embellishment. 

Implementation  of  a  terrain  basis  set  brings 
other  significant  changes  to  the  data  base 
development  process.  The  total  amount  of  geometry 
that  needs  to  be  modeled  is  dramatically  reduced. 
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since  only  one  version  of  each  basis  set  element 
must  be  created.  Thus  the  modeler  can  spend  much 
more  time  optimizing  the  artistic  aspects  of  each 
patch  while  dealing  thoroughly  with  how  the  patch 
loads  the  IG.  This  approach  substantially 
separates  the  geometric  modeling  problem  from  the 
organizational  and  hierarchical  problems,  and  in 
effect  puts  a  lid  on  the  total  amount  of  scene 
elements  which  must  be  created.  The  data  base 
designer  is  thus  freed  of  a  great  deal  of 
modeling  busywork,  while  being  strongly  induced 
to  concentrate  on  and  optimize  the  hierarchical 
aspects  of  the  data  base. 

The  basis  set  approach  also  alleviates 
several  of  the  major  IG  bottlenecks  which 
heretofore  prevented  effective  NOE  imagery.  The 
terrain  basis  set  and  the  embellishment 
components  constitute  a  comparatively  small 
amount  of  data,  and  most  of  this  data  will 
probably  reside  in  the  IG  memories  all  the  time. 
Traffic  at  the  disk  interface  is  greatly  reduced, 
and  most  of  the  disk  to  IG  transfers  involve 
blocks  of  management  and  structure  data,  not 
geometry.  Because  the  basis  set  elements  enjoy  a 
very  high  reusage  factor,  the  apparent  visual 
density  of  the  scene  is  much  higher. 

A  SPECIFIC  NOE  EXAMPLE 

Let's  se«  how  all  of  these  strategies  can  be 
brought  together  to  solve  a  specific  problem.  We 
will  reconsider  the  original  Hunter  -  Liggett  NOE 
problem,  and  derive  a  data  base  design  which 
provides  the  high  level  of  visual  cueing  required 
without  exceeding  the  capabilities  of  the  CT5A. 
DMA  data  will  be  used  to  define  the  offset 
vectors  and  assign  associated  basis  set  patches. 

Our  goal  is  to  display  3000  polygons  in  the 
forward  hemisphere  of  the  pilots  field  of  view. 
This  will  provide  an  adequate  reserve  of  system 
capacity  for  complex  target  areas  and  detailed 
threat  aircraft.  We  will  need  to  have  about  10000 
active  polygons  in  the  vicinity  of  the  viewer  in 
order  to  display  3000  after  FOV  and  backface 
culling.  The  data  base  will  have  four  levels  of 
scale,  desig  ed  to  support  flight  over  an 
altitude  range  of  three  to  100  meters.  One  of 
these  is  the  terrain  skin  itself;  the  other  3  are 
various  sizes  of  trees,  shrubs  and  rocks.  We  will 
arbitrarily  divide  the  total  polygon  allocation 
to  give  the  terrain  2500  polygons  and  each  level 
of  scale  2500.  The  data  base  design  will 
anticipate  an  overall  size  of  25  by  25  kilometers 
and  a  general  visibility  range  of  two  kilometers. 

If  all  2500  of  our  terrain  polygons  are  used 
to  define  a  single  level  of  detail  terrain  skin 
within  the  two  kilometer  visibility  range,  the 
average  area  of  each  polygon  will  be  about  71 
meters  square.  We  will  instead  provide  two  levels 
of  detail.  Within  350  meters  of  the  viewer  the 
average  terrain  polygon  area  will  be  34  meters 
square;  between  350  and  2000  meters  an  average  of 
five  of  these  polygons  will  be  gathered  together 
and  replaced  by  a  single  polygon.  The  low  level 
of  detail  polygons  will  be  specifically  defined 
while  the  high  level  of  detail  will  be  instances 
chosen  from  a  terrain  basis  set.  This  wilt 
require  the  compilation  and  storage  of  about 
106000  polygons  for  the  terrain  low  level  of 
detail;  about  2200  of  these  will  reside  in  the  IG 
memories  at  any  one  time. 


The  smallest  level  of  scale  will  be  provided 
by  randomly  distributed  shrubs  and  rocks  up  to 
three  meters  in  size.  We  will  provide  three 
visual  representations  for  each  item:  three, 
seven  and  15  polygons.  These  might  correspond  to 
a  simple  tetrahedron  tree,  a  tree  with  a  trunk 
and  shadow,  and  a  tree  with  several  tiers  of 
leaves.  We  will  use  some  of  this  capacity  to 
provide  2D  ground  textural  cues  by  depicting 
collections  of  rocks  and  pebbles;  this  will  help 
provide  the  proper  spatial  distribution  of  cues 
when  the  pilot  is  closest  to  the  ground.  Since  we 
are  using  fade  level  of  detail,  the  level  of 
detail  changes  can  take  place  at  20  and  40 
meters,  and  the  simplest  representation  can  be 
entirely  removed  from  the  scene  at  80  meters. 
With  these  parameters  the  spacing  of  ground 
texture  cues  (rocks)  is  about  two  meters. 
Vertical  cues  (trees)  are  available  every  nine 
meters,  and  the  total  number  of  active  polygons 
is  the  desired  2500. 

Each  terrain  patch  has  an  average  of  29  of 
these  small  items  on  it,  with  each  item  requiring 
15*7*3  polygons,  for  a  total  of  about  725 
polygons.  Scene  elements  for  the  middle  level  of 
scale  will  be  about  twice  as  large,  with 
corresponding  increases  in  spacing  and  transition 
ranges,  and  the  large  level  of  scale  will  be  two 
times  bigger  still,  depicting  trees  up  to  12 
meters  in  height.  These  other  two  levels  of  scale 
will  add  another  181  and  45  polygons 
respectively,  to  each  terrain  basis  patch.  Thus 
the  total  number  of  polygons  required  to  create 
each  terrain  patch  is  about  950.  If  we  decide 
that  a  basis  set  of  31  patches  will  provide 
adequate  terrain  fidelity,  the  total  number  of 
polygons  in  the  entire  basis  set  will  be  about 
29000.  Nearly  all  of  these  will  probably  reside 
in  the  IG  memories;  adding  in  the  2200  low  level 
of  detail  terrain  polygons  gives  a  total  memory 
requirement  for  this  data  base  of  about  31000 
polygons.  Data  rate  between  the  disk  and  IG 
memories  would  be  about  30  polygons  per  second. 
Note  also  that  the  overall  size  of  the  data  base 
can  be  expanded  without  changing  the  amount  of  IG 
memory  required  or  increasing  traffic  at  the 
disk . 

The  density  of  the  resulting  data  base  is 
around  520000  polygons  per  square  kilometer, 
counting  only  the  most  complex  version  of  each 
scene  element.  The  optical  flow  requirements 
suggested  by  Sinacori  have  been  met,  and  this 
data  base  can  be  expected  to  properly  support 
flight  down  to  three  meter  eyeheights.  The  total 
amount  of  real  modeling  effort  is  very  small, 
since  most  of  the  detail  is  generic  and  can  be 
produced  by  compile  time  software  tools.  None  of 
the  IG  limitations  have  been  reached,  and  a  large 
cushion  of  performance  has  been  left  to  allow 
substantial  enhancement  of  local  target  areas. 
The  terrain  fidelity  is  as  good  as  DMA  level  2 
data  will  provide. 

A  SAMPLE  BASIS  SET 

A  preliminary  NOE  terrain  basis  set  is  shown 
in  figures  1-4.  The  amount  of  geometry  included 
in  the  basis  set  is  designed  to  provide  a  nominal 
amount  of  cueing  to  support  NOE  flight  at 
altitudes  of  around  three  meters  everywhere  in 
the  data  base.  This  sample  was  designed  to 
closely  accomodate  Sinacori's  recommended  design 
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parameters.  Cultural  and  natural  detail  can  be 
added,  as  well  as  specific  navigational  cues  and 
target  deployment  areas.  Many  variations  of 
terrain  basis  set  geometry  can  be  designed  and 
used  in  the  data  base  interchangeably.  The  sample 
photographs  were  taken  with  a  horizontal  channel 
field  of  view  angle  of  70  degrees. 

SOME  PROBLEMS  REMAIN 

These  techniques  add  a  very  useful  new  tool 
to  the  data  base  designers  kit;  like  other  tools, 
it  may  not  be  the  best  solution  for  every 
problem.  While  the  above  strategy  gets  us  a  long 
way  down  the  road,  some  significant  problems 
remain.  We  have  separated  much  of  the  geometric 
data  from  the  management  information,  and  have 
found  ways  to  reuse  the  geometric  data  with 
fairly  high  leverage.  The  data  base  now  derives 
its  specificity  from  the  structural  data  which 
organizes  the  basis  set  elements;  while  this  is  a 
much  more  efficient  and  compact  type  of  data, 
there  are  still  limits  to  the  amount  that  can  be 
created,  stored  and  processed.  The  NOE  example 
above  will  exceed  these  limits  if  the  total 
geographic  area  is  greatly  increased.  One 
solution  is  to  decrease  the  geographic  density  of 
the  structure  information  by  using  larger  basis 
set  terrain  patches.  Trading  off  terrain 
complexity  for  larger  gaming  areas  may  well  be  a 
viable  solution,  since  a  larger  data  base  implies 
a  higher  flight  velocity  and  altitude. 

The  inclusion  of  specific  lineal  features 
such  as  roads  continues  to  be  difficult  and 
inefficient,  and  adding  specific  3D  cultural 
features  requires  additional  effort.  The  process 
described  above  does  allow  the  merging  of 
specific  scene  details  onto  the  instanced 
patches,  but  much  of  the  advantages  are  reduced. 
This  is  also  an  area  where  the  DMA  data  source  is 
not  especially  helpful;  the  Level  V  and 
subsequent  forms  promise  to  alleviate  some  of 
this  problem.  As  we  continue  to  define  better  and 
more  automated  data  base  development  strategies, 
and  hardware  which  processes  such  data  bases  more 
efficiently,  better  cooperation  between  DMA  and 
those  who  specify,  develop  or  use  these  data 
bases  can  be  very  beneficial. 

CONCLUSIONS 

The  'nap  of  earth'  mission  places 
extraordinary  demands  on  current  CIG  technology. 
Historical  methods  of  producing  and  displaying 
such  data  bases  have  been  inadequate.  A 
fundamentally  different  way  of  dealing  with  the 
problem  has  been  examined.  This  new  approach 
uses  the  concept  of  a  basis  set  to  create 
specific  terrain  from  reusable  terrain  patches 
and  scene  components.  This  methodology  is 
supported  by  new  data  base  design  and  production 
strategies,  and  by  powerful  features  within  the 
CT5A  hardware.  Together  these  provide  the 
capability  to  produce  and  display  visual  data 
bases  wh:ch  effectively  support  'nap  of  earth' 
training  missions.  DMA  data  can  be  used  in  this 
process  to  provide  terrain  fidelity  and 
correlation  with  other  simulation  processes,  and 
has  the  potential  to  substantially  automate  the 
data  base  production  process. 
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ABSTRACT 

The  use  of  computer-based  training  (C8T)  is  rapidly  becoming  more  widespread  within  the 
military  services.  Courseware  production,  historically  the  most  cost  and  labor  intensive  area 
of  C8T,  will  become  more  difficult  with  the  dec  line  in  availability  of  capable  author i ng 
personnel.  Reasons  for  this  decline  and  a  potential  solution — the  development  of  advanced 
authoring  systems — are  discussed.  A  description  of  one  such  system,  called  ADAPT^M  (for  the 
TICCIT*  C8T  system).  Is  presented.. 


As  training  requirements  In  the  military  services 
become  more  critical  and  training  resources  such  as 
fuel  and  Instructor  personnel  become  less  available, 
the  use  of  computei — based  training  (C8T)  has 
Increased  dramatically.  C8T  systems  are  becoming 
less  expensive,  less  bulky,  and  more  capable  with  new 
hardware  (such  as  microcomputers  and  videodiscs)  and 
software  developments.  The  authoring  of  courseware 
remains  the  most  critical  and  cost/labor  Intensive 
part  of  C8T  development,  but,  unfortunately,  the 
availability  of  capable  authoring  personnel  In  the 
military  1 s  on  the  dec  I  I ne . 


C8T  COURSEWARE  AUTHORING  IN  THE  MILITARY 

Military  organ Izat I ons  w I th  responsibility  for 
production  of  C8T  courseware  must  not  only  deal  with 
the  normal  problems  encountered  In  C8T  production  but 
must  also  cope  with  the  following  personnel  problems: 

1.  Lack  of  personnel  with  the  aptitude  required  to 
create  on-line  Instruction  using  conventional 
authoring  languages. 

2.  Lack  of  personnel  experienced  in  the  development 
and  production  management  of  C8T  materials. 

3.  Rapid  turnover  of  personnel  due  to  periodic 
reass i gnment . 

We  w 1 1  I  d I scuss  each  of  these  briefly  be  I ow. 


Lack  of  Personnel  with  an  Aptitude  for  CBT 

The  lack  of  personnel  with  the  aptitude  required 
to  put  Instruction  on  line  Is  a  special  case  of  the 
general  problem  confronting  the  military  services  In 
the  1980s  and  1990s.  The  problem  is  the  lack  of 
manpower  due  to  the  decline  In  the  population  of  18 
to  25  year  olds.  The  military  services  must  compete 
during  these  years  with  all  other  branches  of  society 
for  the  best  of  these  young  people.  In  the  absence 
of  a  draft.  It  is  likely  that  the  most  talented  of 
these  young  people  will  either  pursue  advanced 
educational  opportunities  or  seek  well  paid  positions 
In  business  and  Industry. 

In  addition  to  the  problem  of  securing 
Individuals  with  good  general  intelligence,  the 


military  services  will  find  it  especially  harp  tu 
recruit  young  people  with  aptitude  1  r 
computer-related  areas.  As  the  computer  industry 
becomes  a  dominant  force  in  the  United  States, 
competition  for  such  Individuals  will  become 
particularly  intense. 


Lack  of  Personnel  with  Experience,  in  Developing  CBT 

Training  personnel  In  the  military  services  have, 
for  the  most  part,  only  had  experience  with  workbook 
and  stand-up  Instruction,  with  little  or  no 
opportunity  to  work  with  computer-based  instruction. 
Those  few  military  personnel  who  have  worked  with  CBT 
are  likely  to  have  had  contact  with  the  early  (and 
largely  experimental)  efforts  to  Implement  CBT  in  the 
military.  As  a  resu 1 1  most  ml  I i tary  personnel 
responsible  for  training  are  either  Inexperienced 
with  C8T  (and,  therefore,  do  not  like  or  trust  It)  or 
may  be  biased  against  It  based  on  prior  experiences. 

Even  when  men  and  women  In  the  military  services 
demonstrate  ability  for  and  Interest  In  developing 
CBT  materials,  there  Is  no  clearly  defined 
appropriate  career  path  for  such  personnel.  In  fact, 
even  if  an  Individual  acquires  advanced  training  In 
the  systematic  design  of  CBT  instruction  In  general 
or  the  authoring  of  on-line  material  in  particular, 
there  may  be  a  negative  Incentive  In  terms  of  career 
advancement  to  remain  In  the  CBT  field. 


Rapid  Turnover  of  CBT  Personnel 

Given  the  normal  rapid  turnover  of  personnel  In 
the  military  and  the  lack  of  a  defined  career  path  in 
C8T,  the  tew  trained  and  experienced  CBT  personnel 
that  do  develop  at  military  authoring  sites  are 
usual ly  rotated  to  other  assignments,  often  just  as 
they  become  proficient  and  when  they  are  most  needed. 

These  factors  severely  compl  icate  the  task  of 
military  organizations  that  seek  to  become 
cost-effective  producers  of  C8T.  Some  of  these 
problems  such  as  lack  of  a  CBT  career  path  require 
high-level  changes  In  the  military  services  to  cause 
any  lasting  Improvement.  Others  such  as  the  decline 
In  computer  aptitude  may  be  effectively  combatted 
through  the  use  of  advanced  authoring  systems  such  as 
the  one  discussed  below. 


3» 


AUTHORING  SYSTEMS 


Authoring  systems  are  on-line  editing  packages 
designed  to  aid  the  author  In  the  development  of 
courseware.  Authoring  systems  Interface  with  the 
author  through  an  on-line  editor,  which  usually  takes 
a  nonprogrammi ng  format.  Authoring  systems  can 
provide  aid  In  a  variety  of  areas  such  as  front-end 
analysis  for  a  course,  the  development  of  Individual 
displays  within  a  lesson,  and  course  management. 

In  the  past  the  method  for  authoring  courseware 
was  usually  a  programming  language,  ranging  from 
general-purpose  languages  like  BASIC  or  PASCAL  to 
specialized  languages  optimized  for  courseware 
production  like  TUTOR  for  PLATO*  or  TAL  (TICCIT* 
Authoring  Language)  for  TICCIT.  (The  latter  type  are 
very  powerful  but  require  considerable  training  to 
master  fully.)  On-line  courseware  authors,  therefore, 
must  either  be  programmers  or  have  a  programming 
aptitude.  The  profile  of  authors  available  for  the 
military,  however,  demands  that  authoring  be 
Independent  of  programming  as  much  as  possible. 

Authoring  systems  may  be  presented  In  various 
formats  Including  prompt-driven,  menu-driven,  and 
programming. 


Each  of  the  above  formats  has  Its  advantages  anc 
disadvantages.  An  iceal  authoring  system,  then, 
could  use  all  three  formats  at  different  times 
depending  on  an  author's  aptitude  and  current 
expertise.  One  such  system  Is  currently  being 
developed  by  Hazeltine  Corporation.  The  design 
cons  1  aer at  1  ons  in  this  system  should  prove  useful  In 
any  C8T  environment.  The  remainder  of  this  paper 
presents  a  description  of  this  authoring  system. 

ADAPT™:  A  MJLTILEVa  AUTHORING  SYSTEM 

Hazeltine  Corporation,  manufacturer  of  the  TICCIT 
C8T  system,  in  conjunction  with  the  rehosting  of  that 
system  to  run  on  a  microcomputer,  is  currently 
developing  a  new  authoring  system  to  meet  the 
requirements  of  military  CBT  authors  discussed  above. 
The  guiding  considerations  for  this  new  system, 
called  ADAPT™,  are  that  different  authors  possess 
different  levels  of  expertise  and  that  different 
instructional  objectives  require  different 
presentation  strategies.  The  authoring  system, 
therefore,  may  be  entered  at  a  variety  of  levels 
depending  on  the  current  ability  of  the  author  and 
the  instructional  design  -equirements  of  the  material 
being  authored. 


Prompts  are  questions  presented  to  the  author  by 
the  on-line  editor.  A  prompt-driven  authoring  system 
leads  the  author  through  the  authoring  process  by 
asking  a  series  of  questions.  Prompting  Is  very 
effective  for  the  new  author  but  quickly  becomes 
unnecessary  as  the  author  gains  experience.  There 
are  simply  too  many  options  to  be  able  to 
Individually  question  more  than  just  the  basic  ones. 
Also,  authors  soon  learn  the  options  used  most 
frequently,  at  which  point  the  prompts  Inhibit 
efficient  authoring. 


Menu-dr  1  yen 

In  a  menu-driven  authoring  system,  many  options 
may  be  presented  simultaneously  on  each  menu.  This 
allows  authors  to  move  more  rapidly  through  the 
production  process.  Also,  commonly  used 
Instructional  templates,  such  as  particular  practice 


We  may  think  of  a  lesson  file  In  ADAPT  as  being 
created  at  any  position  within  a  two-dimensional 
matrix  of  authoring  expertise  versus  Instructional 
design  model.  (Figure  1  presents  a  schematic 
representation  of  this  concept.)  Along  one  axis  are 
levels  of  editor  formats  based  on  those  discussed 
above.  Along  the  other  axis  are  various 
instructional  design  presentation  strategies  for 
developing  lessons  for  particular  classes  of 
Instructional  objectives  (such  as  concept 
classification,  rule  using,  linear  procedures, 
simulations,  etc.)  plus  the  option  of  having  no 
embedded  strategy.  Since  the  Intended  audience  for 
ADAPT  Is  not  Instructional  designers,  these 
strategies  will  be  presented  In  terms  that  will  be 
meaningful  to  the  military  author.  When  creating  a 
file,  the  author  selects  the  point  In  this  matrix 
that  represents  his  or  her  current  need — the 
Intersection  of  the  desired  authoring  level  and  the 
appropriate  instructional  strategy.  (Eventually,  the 
front-end  analysis  capability  of  ADAPT  will  lead  the 
author  to  the  selection  of  the  strategy.) 


Item  formats,  can  be  presented  quickly  and  repeatedly 
by  menus.  Unfortunately,  menu-driven  authoring 
systems  normally  must  contain  multiple  levels  of 
menus  because  of  the  large  number  of  options  required 
In  a  sophisticated  CBT  environment.  As  with 


prompt-driven  systems,  authors  quickly  learn  those 
options  that  are  most  frequently  used.  At  this  point 
the  authors  need  shortcuts  around  the  majority  of  the 
menus. 


Program  I  no 

Specialized  programming  authoring  languages 
remain  the  most  powerful  and  flexible  means  of 
authoring  CBT  materials.  Invariably,  there  are  times 
when  even  the  best  of  menu-driven  formats  cannot 
adequately  support  the  production  of  a  particular 
Instructional  requirement.  At  that  point  the 
programming  format  is  required.  The  major  problem 
with  such  languages  Is  the  need  for  extensive 
training  and  a  programming  aptitude. 


Editor 

Format 


4)  Coding 
3)  Complete  menus 
2)  Simple  menus 
1 )  Prompts 


Instructional  Strategy 


Figure  1 — Matrix  representing  the  ability  to  select 
authoring  level  and  Instructional  strategy 
for  an  ADAPT  file. 
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There  are  four  levels  of  editor  formats  available 
ranging  from  level  1  (the  lowest)  to  level  4  (the 
highest): 

Level  I,  for  the  novice  author,  Is  a 
prompt-driven  format  In  which  the  author  Is  led 
through  the  authoring  process  by  means  of  a  series  of 
questions  (prompts).  These  prompts  cover  a  limited 
set  of  options  for  the  beginning  author  to  consider. 
The  author  provides  the  data  required  for  these 
prompts  by  answering  yes/no  questions  and  by  typing 
Engl  lsh-1  ike  data  statements. 

When  the  author  no  longer  needs  to  be  led  step  by 
step,  he  or  she  may  move  to  level  2,  which  abandons 
the  prompts  and  directly  presents  the  same  limited 
set  of  options  through  simple  menus.  Figure  2 
presents  one  such  menu. 


Additions  to  the  Displat. 


Answer  checking  . Exists 

Graphic  .  Exists 

Video  . .  None 

Audio  . .  None 

Time  limit  (in  seconds)  .  10 

Remarks  .  None 


Figure  2 — Level  2  additions  menu. 

Level  3,  for  the  intermediate  author,  presents 
the  full  set  of  options  through  complete  menus. 

Some  of  the  new  options  may  require  the  author  to 
supply  data  In  a  coded  syntax.  Figure  3  presents 
the  level  3  version  of  the  menu  presented  In  Figure 
2.  (Note  that  color,  which  Is  an  Important  aspect 
of  ADAFT,  Is  not  visible  In  these  figures.)  Level  3 
represents  a  powerful  authoring  capability  with 
which  the  bulk  of  courseware  at  most  sites  may  be 
authored. 


An  Important  feature  of  ADAPT  Is  that  a  file 
authored  at  one  level  may  be  raised  at  any  time  to  a 
higher  level.  At  all  levels  the  author  Is  creating 
programming  code  such  as  that  at  level  4.  It  Is  only 
at  level  4  that  the  author  sees  this  code  directly. 
The  various  lower  levels  are  simply  editing  formats 
that  lie  between  the  author  and  the  resultant  code. 
For  example,  a  menu  for  answer  checking  under  level  3 
presents  all  the  options  associated  with  a  COMPARE 
command  at  level  4.  At  level  3  the  options  are 
listed;  at  level  4  the  author  must  know  which  options 
he  or  she  needs  to  add.  (Even  at  level  4,  on-line 
advice  about  which  options  are  available  and  how  each 
i s  used  I s  aval  I ab I e. ) 


At  the  creation  of  a  file,  the  author  may  select 
an  embedded  Instructional  presentation  strategy  that 
Is  suited  to  the  particular  objective  being  taught. 
These  strategies  are  Included  to  ensure  the 
Instructional  soundness  of  the  on-line  material, 
particularly  as  an  aid  to  the  author  lacking  In 
instructional  design  experience.  This  Is 
accomplished  by  listing  the  required  and  optional 
Instructional  components  (e.g.,  objective, 
generality,  practice  Items,  helps,  etc.)  for  each 
strategy  as  well  as  the  requirements  within  each 
component  (e.g.,  answer  checking  for  a  practice 
item).  The  authoring  system  can  even  lead  the  author 
through  the  process  of  picking  the  appropriate 
strategy . 


We  will  now  look  at  the  creation  of  an  Individual 
display  In  some  detail.  (Ultimately,  It  Is  possible 
to  consider  any  student  presentation  as  being  a 
series  of  screen  displays  presented  to  the  learner. 
The  particular  sequence  of  displays  and  the  details 
of  each  display  will  depend  on  what  the  learner  does 
while  using  the  material.)  The  authoring  of  each 
screen  Is  enhanced  through  the  use  of  two  components: 
(1)  a  display  page  and  (2)  an  "additions"  menu. 


•istlay  construction: 

Clear  screen  before  display?...  Yes 


Palette  .  System 

Variable  display  data  .  Exists 

Graphic  .  None 

Motion  .  None 

Video  . Exists 

Audio  .  None 

Timeout  (seconds)  .  None 

USfONSE  ANALYSIS  : 

Branch  table  .  Seen 

Answer  checking  .  Exists 


Figure  3 — Level  3  additions  menu. 


Level  4,  for  the  advanced  author,  Is  the 
programming  authoring  language  with  Its  complete 
capabilities  and  flexibility.  Here,  the  author 
creates  progran  code  using  the  required  syntax. 
Some  menus  are  available  at  this  level  if  desired 
to  simplify  options  such  as  the  scoring  and 
sequencing  of  practice  and  example  Items. 


The  display  page  Is  a  clear  screen  on  which  the 
author  may  type  directly  (l.e..  In  the  desired 
position  and  color)  all  text  that  will 
unconditionally  appear  on  the  resulting  student 
screen . 

The  additions  menu  is  a  listing  of  options  by 
which  the  author  can  modify  the  contents  of  the 
display.  At  ADAPT  level  2  these  options  include 
answer  checking,  graphics,  video  and  audio  sequences 
(including  the  overlaying  of  text/graphics  on  the 
video  frames),  and  a  time  limit.  (See  Figure  2.) 
Author  documentation  of  the  display  I s  a  I  so  aval  I ab I e 
through  this  menu.  Further  options  are  available  at 
level  3,  such  as  graphics  animation  sequences 
(motion),  color  palette,  and  conditional  text 
(variable  display)  data  based  on  the  run-time 
environment.  (See  Figure  3.) 

All  of  the  level  3  options  are  available  at  level 
2  If  they  are  specifically  requested  by  the  author. 
Once  a  higher  level  option  Is  Invoked  on  a  lower 
level  additions  menu,  the  option  will  remain  on  the 
menu.  This  ability  Is  facilitated  by  the  nature  of 
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the  menus  themselves.  An  author  may  choose  an  option 
by  either  touching  It  with  the  light  pen  or  by  typing 
the  first  three  letters  of  the  option  name  on  the 
bottom  line  of  the  terminal  screen.  The  latter 
method  allows  the  use  of  options  that  do  not 
currently  appear  on  the  screen.  It  also  allows 
options  to  be  chained  (i.e.,  a  sequence  of  options 
may  be  typed  at  the  same  time),  thus  avoiding  the 
need  to  see  all  the  Intervening  menus.  This  feature 
alone  removes  one  of  the  major  problems  associated 
with  menu-driven  authoring  formats. 

At  level  4  the  display  page  for  unconditional 
text  remains  the  same,  but  the  additions  to  the 
display  are  accomplished  through  the  use  of  specific 
programming  commands  which  the  author  Inserts  in 
command  sections  following  the  display  page.  For 
example,  graphics  are  provided  through  GRAPHIC 
commands,  answer  checking  through  COMPARE  commands, 
and  conditional  text  data  through  SHOW  commands. 


On-line  Training 

The  large  amount  of  training  required  before 
authors  can  efficiently  produce  useable  courseware 
has  been  a  problem  with  authoring  languages  in  the 
past.  In  ADAPT  the  Initial  training  requirement  is 
minimized,  first,  by  the  prompting  format  at  level  1 
(which  leads  the  author  through  the  authoring 
decisions)  and  second,  by  the  limited  number  of 
options  available  at  levels  I  and  2. 


necessary  training  at  that  time  and  then  proceed.  At 
some  sites  the  editor  could  even  lock  out  particular 
authors  from  certain  levels  or  options. 


CONCLUSIONS 

An  advanced  author  ng  system  like  the  one 
cescribed  above  Is  a  potential  solution  to  some  of 
the  problems  faced  by  the  military  In  the  authoring 
of  C8T  courseware.  Such  a  system  can  overcome  a 
lack  of  programming  aptitude  among  military  authors 
by  removing  the  need  for  programming.  A  great  deal 
of  the  Instructional  material  can  be  input  by 
personnel  lacking  programming  skills  or  experience. 
Material  requiring  such  skills  can  then  be  left  to 
those  Individuals  able  to  input  them.  Similarly, 
the  authoring  system  can  overcome  the  lack  of  C8T 
design  expertise  by  providing  built-in  instructional 
models  that  help  ensure  that  the  on-line  material  is 
fully  consistent  with  the  most  effective  teaching 
and  learning  strategies  available.  Such  an 
authoring  system  thus  helps  to  alleviate  the  problem 
of  rapid  turnover  by  quickly  allowing  new  authors  to 
produce  useab I e  mater  I  a  I .  This  allows  a  site  to 
make  better  use  of  Its  authoring  personnel  even  It 
there  Is  no  change  In  the  rate  of  personnel  turnover 
or  In  the  Incentives  for  remaining  In  a  CBT 
authoring  role.  Also,  the  on-line  training  will 
help  those  authors  with  an  aptitude  for  programming 
more  quickly  master  the  advanced  authoring 
capabilities  and  techniques. 


Training  for  level  1,  then,  involves  basic 
Instruction  In  the  use  of  the  ADAPT  editor  (getting 
started,  labeling  files,  etc.)  and  explanations  of 
some  of  the  options  to  be  prompted.  In  addition  to 
the  training,  explanations  of  current  options  are 
always  available  within  the  editor  through  the  ADVICE 
key. 

For  level  2,  the  only  additional  training 
required  Is  In  how  to  move  among  menus  and  the 
explanation  of  any  new  options  (still  from  the 
limited  subset)  that  were  not  addressed  by  the 
prompts  at  level  1 . 

Level  3  requires  training  for  the  new  options 
available.  For  the  most  part,  though,  the  menu 
structure  Is  the  same  as  for  level  2 — just  more 
options  per  menu.  In  addition,  some  of  the  new 
options  require  coding  syntax  to  enter  data.  This 
represents  a  higher  sublevel  within  level  3  with 
appropriate  training  necessary. 

Level  4  Involves  the  use  of  commands  and  full 
programming  syntax.  Since  these  commands  have  the 
same  names  as  the  menu  options  they  represent,  to 
some  extent  the  training  requirement  Is  lessened. 
Similarly,  the  syntax  learned  In  level  3  Is  also  used 
In  level  4. 

Thus,  there  Is  a  discrete  training  requirement  at 
each  level  and  sublevel.  This  training  will  be 
presented  on-line  and  with  hard  copy  job  aids  and 
review  materials.  The  editor  will  be  aware  of  the 
current  level  of  training  accomplished  by  each  author 
and  can  Interrupt  whenever  an  author  attempts  to 
raise  a  file  to  a  level  for  which  he  or  she  has  not 
been  trained  or  use  an  option  not  yet  presented  In 
the  training.  At  that  point  the  author  may  choose  to 
Ignore  the  editor's  warning  and  proceed  with  the 
option  or  level  change,  or  the  author  may  receive  the 
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ABSTRACT 

Two  general  types  of  programming  languages  have  been  developed  for  computer  based  educational 
systems.  The  first  type  of  language,  which  is  patterned  after  such  high  order  languages  as 
PASCAL  or  FORTRAN,  provides  great  programming  flexibility.  However,  its  structured,  syntac¬ 
tical  constructs  require  either  that  an  experienced  programmer  be  involved  in  lesson  generation 
or  that  instructional  personnel  become  skilled  in  sound  programming  techniques.  Its  use 
frequently  results  in  other  problems  as  well,  such  as  communicat ion  difficulties  between 
instructional  and  programming  personnel  in  the  implementation  of  the  lesson  design  and  develop¬ 
ment  process.  To  avoid  these  problems,  the  second  type  of  language  was  developed.  It  allows 
instructional  personnel  to  generate  on-line  instructional  materials  without  acquiring  sophis¬ 
ticated  programming  skills.  This  second  category  of  languages  is  often  thought  of  as  being 
"user  friendly."  Such  languages  usually  take  an  algorithmic  approach  to  instruction  and  rely 
heavily  on  prompting  as  the  means  of  lesson  program  entry.  -They  serve  very  well  for  many 
applications,  but  their  use  has  not  been  without  problems.  Not  the  least  of  these  problems  has 
been  a  lack  of  flexibility  in  the  presentation  and  creation  formats.  This  paper  describes  the 
OMEGA  authoring  system,  a  lesson  authoring  approach  that  provides  instructional  personnel  with 
the  positive  features  of  both  of  the  above  language  types.  The  approach  has  been  implemented 
on  an  educational  system  that  includes  capabilities  for  the  integrated  use  of  interactive 
videodisc  and  three  dimensional  simulation.  -The  paper  first  relates  some  basic  facts  about 
computer  systems  in  general,  and  then  discusses  the  various  aspects  of  user  friendliness  in  the 
context  of  educational  programming.  It  then  describes  and  evaluates  both  the  traditional  and 


OMEGA  approaches  to  user  friendly  authoring. 


Users  of  educationally  oriented  computer 
systems  have  a  limited  number  of  authoring  lan¬ 
guage  options  available  to  them.  Most  systems  are 
equipped  with  two  types  of  authoring  languages. 
The  first  type  offers  the  author  a  great  deal  of 
flexibility  in  instructional  design,  but  requires 
a  very  sophisticated  knowledge  of  computer  pro¬ 
gramming  to  be  used  effectively.  The  type,  which 
is  advertised  by  manufacturers  as  "user  friendly," 
requires  little  or  no  computer  background,  but 
limits  the  author  to  a  relatively  rigid  instruc¬ 
tional  presentation  format. 

Today’s  instructional  environment  requires  a 
language  option  that  is  more  adaptable  than  either 
of  the  two  discussed  above.  An  author's  computer 
background  can  range  from  nonexistent  to  exten¬ 
sive,  and  instructional  applications  vary  from 
simple  to  extremely  complex. 

This  paper  describes  the  OMEGA  authoring 
system  developed  by  the  Training  Systems  Depart¬ 
ment  of  the  Grumman  Aerospace  Corporation.  OMEGA 
was  designed  to  bridge  the  gap  between  the  lan¬ 
guage  option  types  discussed  above.  It  combines 
adaptability  to  any  level  of  computing  ability 
with  the  flexibility  and  power  required  for 
sophisticated  instructional  applications. 

The  paper  first  discusses  a  few  basics  of 
computers  to  define  terms  used  in  the  discussion 
that  follows.  That  discussion  begins  with  a 
description  of  the  various  aspects  of  user  friend¬ 
liness.  It  then  describes  and  evaluates  the 
approaches  that  have  traditionally  been  taken 
toward  making  educationally  oriented  computer 
systems  user  friendly.  Finally,  the  OMEGA 
approach  to  lesson  authoring  will  be  described  and 
evaluated . 


COMPUTER  ESSENTIALS 

A  computer  is  basically  a  piece  of  ma¬ 
chinery  that  uses  electronic  means  to  manipulate 
data.  The  machinery  —  called  "hardware"  in 
computer  jargon  —  consists  of  a  processor  and 
various  support  items  known  as  "peripherals." 
These  peripherals  allow  the  processor  to  communi¬ 
cate  and  interface  with  the  outside  world.  Some 
peripherals  (e.g.,  keyboards  and  card  readers)  are 
called  "input"  devices;  they  allow  the  user  to 
give  information  to  the  processor.  Other  per¬ 
ipherals  (e.g.,  printers  and  terminals)  are  known 
as  "output"  devices;  they  allow  the  processor  to 
display  information  for  the  user.  Mass  memory  is 
one  of  the  most  important  peripherals  in  a  com¬ 
puter  system.  It  stores  data  that  is  not  cur¬ 
rently  being  used  by  the  processor,  but  which  will 
be  required  at  some  future  time.  This  memory  is 
both  an  input  and  an  output  device,  since  the 
processor  "reads"  from  it  or  "writes"  to  it. 

Computer  hardware  is  controlled  by  programs, 
or  "software."  These  programs  are  nothing  more 
than  structured  sets  of  instructions  that  can  be 
understood  and  executed  by  the  computer's  pro¬ 
cessor.  Programs  control  the  sequence  and  nature 
of  the  processor's  interactions  with  its  per¬ 
ipherals  and  the  way  it  manipulates  and  formats 
data. 

Programs  can  be  written  in  various  computer 
"languages,"  which,  like  human  languages,  consist 
of  a  vocabulary  and  syntax.  The  "vocabulary”  of  a 
computer  language  is  the  set  of  instructions  (also 
called  commands)  it  contains.  Its  "syntax"  is  the 
set  of  rules  governing  the  way  in  which  the 
instruction?  must  be  structured.  Many  different 
languages  have  been  developed  for  computers  over 
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the  years,  and  several  language  options  are 
usually  available  for  any  given  computer. 

The  most  fundamental  language  for  a  computer 
is  its  "machine  language. H  Each  instruction  in 
machine  language  is  a  series  of  binary  states, 
commonly  represented  by  l's  and  0's.  Machine 
language  is  considered  fundamental  because  all 
programs,  no  matter  what  language  they  are  written 
in,  eventually  become  machine  language.  It  is  the 
only  language  a  computer  "understands,"  and  is 
unique  to  a  particular  processor. 

Programs  can  be  written  directly  in  machine 
language,  but  it  is  very  difficult  to  do  so.  To 
make  the  programming  task  easier,  a  second  type  of 
language,  known  as  "assembly,"  was  developed. 
There  is  a  one  to  one  correspondence  between 
assembly  language  instructions  and  machine  lan¬ 
guage  instructions;  but  the  instructions  in 
assembly  language  are  easily  recognizable  mne¬ 
monics,  and  are  therefore  much  easier  to  work  with 
than  machine  language  instructions.  Programs 
written  in  assembly  language  ("source  code")  are 
mechanically  converted  into  machine  language 
programs  ("object  code")  by  a  utility  program 
known  as  an  "assembler."  Like  machine  languages, 
assembly  languages  are  unique  to  a  given  pro¬ 
cessor  . 

Although  programming  in  assembly  language  is 
much  easier  than  programming  in  machine  language, 
it  is  still  a  tedious  and  time-consuming  task. 
For  this  reason,  various  "high  order"  languages 
(HOLs)  have  been  developed.  Source  code  written 
in  these  languages  is  translated  into  object  code 
using  utility  programs  known  as  compilers  or 
interpreters.  HOLs  differ  from  assembly  language 
in  that  a  single  command  normally  corresponds  to  a 
structured  group  of  machine  language  inst ructions. 

High  order  languages  usually  have  been 
developed  with  specific  applications  in  mind, 
e.g.,  arithmetic  computation,  large  data  base 
management,  string  manipulation,  or  instructional 
delivery.  Their  specific  design  orientations  make 
it  relatively  easy  for  programmers  to  write 
programs  for  their  intended  applications,  but 
programming  for  applications  outside  of  those  for 
which  the  language  was  designed  can  be  very 
difficult  or  inefficient. 

Source  code  for  a  program  written  in  either 
assembly  language  or  an  HOL  is  usually  composed  at 
a  computer  terminal  using  some  sort  of  editing 
program.  The  code  thus  produced  is  put  into  a 
logical  entity,  known  as  a  "file,"  in  computer 
memory.  This  file  is  used  as  input  to  the  assem¬ 
bler,  compiler,  or  interpreter,  as  appropriate,  to 
produce  object  code.  This  object  code  is  put  into 
another  file.  When  executed  by  the  computer,  the 
object  code  causes  the  computer  to  do  the  things 
desired  by  the  programmer. 

A  note  of  clarification  is  perhaps  in  order 
here.  The  user  friendly  language  options  provided 
for  educational  computing  systems  sometimes  make 
it  appear  that  lesson  authoring  is  something  other 
than  programming.  Despite  appearances,  however, 
it  is  important  to  remember  that  the  author  is 
actually  writing  a  computer  program.  It  doesn’t 
matter  what  the  author’s  instruction  set  looks 
like  or  how  the  instructions  are  specified.  When 
the  data  that  is  entered  becomes  machine  language, 


the  computer  treats  it  the  same  as  any  other  data 
base.  Ultimately,  programs  must  he  written  in 
some  computer  language,  and  the  instructions  in 
that  program  must  be  translated  into  the  machine 
language  of  the  computer  being  used. 

ASPECTS  OF  USER  FRIENDLINESS 

A  system  that  is  user  friendly  is  one  that  is 
easy  to  learn  and  use.  There  are  two  approaches 
to  making  a  computer  authoring  system  user  friend¬ 
ly.  One  deals  with  the  language  to  be  used,  while 
the  other  deals  with  the  means  of  producing  source 
code  in  that  language,  or  editing. 

Language 

It  is  obvious  that  a  language  with  compli¬ 
cated  syntax  is  less  user  friendly  than  one  with  a 
simple  and  straightforward  syntax.  In  addition, 
an  instruction  set  consisting  of  mnemonics  that 
are  natural  and  meaningful  to  the  author  will  be 
easier  to  use  than  one  whose  instruction  set  is 
unnatural . 

These  are  the  aspects  of  language  that  are 
most  often  thought  of  relative  to  user  friend¬ 
liness,  but  there  are  others  as  well.  These 
include  the  following: 

Capability:  It  doesn’t  matter  how  simple  a 
language  is  if  it  doesn’t  provide  the  author  with 
the  tools  necessary  to  do  what  is  required.  An 
instruction  set  must  be  complete  enough  to  provide 
flexibility. 

Adaptability :  Closely  tied  to  capability, 
adaptability  implies  that  a  language  can  be  used 
for  diverse  applications.  For  example,  a  language 
developed  only  for  interactive  videodisc  applica¬ 
tions  could  not  be  used  by  an  author  in  applica¬ 
tions  requiring  interaction  with  a  simulator. 

Tolerance  for  Faults/Diagnostics:  Anyone  who 
has  done  any  programming  knows  that  programs 
rarely  run  correctly  the  first  time.  A  useful 
feature  of  any  language  is  toleration  for  such 
faults  as  typographical  errors.  Where  errors 
exceed  the  limits  of  reason,  diagnostics  indi¬ 
cating  what  sort  of  error  has  been  made  (and 
where)  are  a  great  help  in  identifying  what  needs 
to  be  changed  to  make  the  program  run  correctly. 

Editing 

As  was  the  case  with  language  considerations, 
simplicity  is  the  most  obvious  characterise  ic  that 
will  make  an  editor  user  friendly.  The  simpler 
the  editor  is  in  function,  the  easier  it  will  be 
to  learn  and  use  it.  However,  there  are  some 
additional,  and  perhaps  less  obvious,  features 
that  can  be  useful: 

Internal  Helps:  Closely  associated  with 
simplicity,  internal  helps  provide  the  user  with 
assistance  when  he  doesn’t  know  what  to  do  next. 

Speed:  How  fast  can  source  code  be  entered 
on  a  sustained  basis? 

Documentation:  To  what  degree  can  comments 
be  added  to  the  source  code  to  provide  information 
on  program  logic?  This  is  a  very  important 
feature  when  the  author  must  go  hack  into  the 


program  to  correct  errors  or  change  it  for  some 
reason . 


JUDGMENT  CRITERIA 

From  the  foregoing  discussion,  it  is  obvious 
that  there  are  at  least  seven  factors  that  can  be 
used  to  judge  the  user  friendliness  of  a  given 
system: 

o  Simplicity 
o  Capability 
o  Adaptability 

o  Tolerance  for  faults/diagnostics 
o  Internal  helps  when  editing 
o  Editing  speed 
o  Documentation. 

These  criteria  provide  the  basis  for  the  discus¬ 
sion  that  follows. 


HISTORICAL  SYSTEM  DESIGN 

The  most  common  system  design  for  a  user 
friendly  authoring  language  actually  obscures  the 
language  being  used.  The  author  deals  exclusively 
with  an  editor  that  provides  menus  and  templates 
to  extract  the  required  program  information.  As 
the  author  responds,  the  editor  composes  and 
formats  the  requisite  commands,  and  inserts  them 
at  the  required  places  in  the  program.  In  this 
way,  the  authoring  language  is  totally  transparent 
to  the  author.  This  approach  can  be  evaluated  as 
follows: 

Simplicity 

A  template  system  is  very  simple  to  learn. 
Typically,  a  new  author  can  be  on  the  system  and 
working  within  a  few  hours.  Authoring  vocabulary 
and  syntax  are  not  problems,  since  the  author  is 
isolated  from  the  actual  language  base. 

As  simple  as  this  approach  seems,  however, 
there  are  problems  with  it.  While  it  is  true  that 
the  new  author  can  begin  to  work  quickly,  total 
proficiency  comes  much  more  slowly.  A  flexible 
language,  with  extensive  capabilities,  requires  a 
great  many  menus  and  templates,  and  the  sheer 
numbers  may  be  overwhelming  at  first. 

As  proficiency  is  gained,  a  new  problem 
develops.  With  experience,  the  author  outgrows 
the  need  for  many  of  the  prompts  the  system  gives. 
The  speed  with  which  the  author  can  create  reaches 
a  terminal  point,  and  frustration  with  the  system 
sets  in. 

Capability 

As  discussed  above,  the  capabilities  of  this 
type  of  system  may  be  quite  extensive.  The  nature 
of  the  approach,  however,  limits  the  ability  to 
extend  those  capabilities.  Each  new  feature 
requires  not  only  that  new  commands  and  program¬ 
ming  routines  be  prepared,  but  also  that  new  code 
be  written  for  the  editor  that  allows  authors  to 
use  the  feature.  This  is  a  time  consuming  and 
expensive  proposition,  since  the  updated  editor 
must  be  thoroughly  tested  to  ensure  that  the  new 
features  do  not  interfere  with  previously  existing 
features. 


Adapt abi 1 i ty 

This  approach  makes  it  very  difficult  to 
adapt  to  new  applications  tor  the  same  reasons 
listed  for  Increasing  capability.  The  problems 
are  of  the  same  nature,  but  are  more  extensive. 

Tolerance  for  Faui t s/Diagnos t ics 

This  approach  scores  very  high  for  this 
criterion  for  one  potential  error  situation,  since 
the  system  does  not  allow  the  author  to  enter  an 
unrecognizable  command.  Problems  can  result, 
however,  if  an  entry  is  made  that  is  syntactically 
correct,  but  logically  incorrect.  The  recognition 
and  solution  of  this  type  of  error  will  be  ex¬ 
tremely  difficult  and  time  consuming 

Internal  Helps 

This  is  the  strongest  suit  of  the  traditional 
system.  Using  an  editor  of  this  type  provides 
excellent  internal  helps  for  the  author.  The  next 
required  entry  is  always  displayed  on  the  screen. 

Speed 

As  noted  earlier,  the  new  author  can  begin  to 
create  very  rapidly,  and  the  time  it  takes  will 
probably  be  faster  than  would  be  possible  with 
other  systems  at  first.  However,  as  proficiency 
is  gained,  the  prompts  become  a  hindrance. 
Templates  require  that  each  prompt  be  addressed, 
whether  the  feature  it  represents  is  required  or 
not.  This  creates  the  first  bottleneck.  A  second 
problem  is  that  it  takes  a  finite  amount  of  time 
to  perceive  the  prompt  and  respond  to  it. 

Documentation 

The  ability  to  document  the  source  code 
varies  from  one  system  to  another.  Generally 
speaking,  however,  this  approach  does  not  provide 
for  the  extensive  internal  documentation  required 
for  a  sophisticated  program.  This  lack  of 
documentation  severely  curtails  the  usefulness  of 
the  training  system.  Programs  need  to  be  changed 
from  time  to  time,  and  changes  are  not  always  made 
by  the  same  person  who  originally  wrote  the 
program.  A  new  author  may  not  be  able  to  perceive 
the  original  author's  logic  if  it  is  not:  well 
documented,  and  may  be  forced  to  recreate  a  lesson 
from  scratch  as  a  result. 

THE  OMEGA  DESIGN 

The  OMEGA  authoring  system  has  been  designed 
to  incorporate  as  many  of  the  strengths  of  the 
traditional  system  as  possible,  while  overcoming 
its  weaknesses.  It  consists  of  three  elements: 
the  OMEGA  language  itself,  an  editor  used  to 
create  OMEGA  source  code  files,  and  a  set  of  pro¬ 
cedures  developed  for  using  the  editor  effec¬ 
tively. 

The  OMEGA  system  is  designed  to  support 
diverse  instructional  applications,  including 
operation  and  maintenance  of  complex  equipment. 
Unlike  other  authoring  systems,  OMEGA  can  control 
students  as  they  acquire  both  cognitive  skills 
using  two  dimensional  (2D)  media  and  psychomotor 
skills  using  three  dimensional  (3D)  media.  A 
typical  hardware  for  these  training  applications 
could  consist  of: 
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o  A  microprocessor  for  system  control 
o  Mass  memory  in  the  form  of  either  floppy 
or  hard  disks 

o  Mass  video  memory  in  the  form  of  laser 
videodiscs 

o  A  color  television  monitor  to  display 
stored  video  and/or  digital  materials 
o  A  touch  sensitive  bezel,  mounted  on  the 
front  of  the  monitor,  to  allow  student 
inputs 

o  A  voice  recognition  unit  to  allow  for 
student  inputs  when  both  hands  are 
occupied  with  performing  a  manual  task 
o  A  three  dimensional  (3D)  simulator  to 

allow  the  student  to  manipulate  equipment 
as  required  by  the  training  task. 

Lesson  design  and  authoring  for  3D  applica¬ 
tions  can  be  extremely  complex.  Experience  has 
shown  that  it  is  sometimes  necessary  to  anticipate 
15  to  20  responses  at  one  time  while  teaching  the 
troubleshooting  of  a  complex  piece  of  electronic 
equipment.  Sometimes,  half  of  these  are  antici¬ 
pated  incorrect  responses  that  require  remedia¬ 
tion.  The  other  half  in  that  situation  are 
logically  correct  responses.  Each  correct 
response  requires  a  separate  branch  path  in  the 
lesson  that  would  accomodate  the  actions  that 
follow. 

The  system  can  also  be  used  for  more  tradi¬ 
tional  applications.  There  are  times  when  the 
system  is  used  to  present  standard  interactive 
videodisc  instruction,  even  when  dealing  with  very 
sophisticated  equipment.  This  instruction  can 
consist  of  a  basic  series  of  instructional  frames, 
or  "pages,"  to  be  presented  to  the  student.  They 
are  "turned"  when  the  student  indicates  that  he  is 
ready  for  the  next  page,  usually  either  by 
touching  a  designated  spot  on  the  screen  or  by 
giving  a  verbal  command  using  the  voice 
recognition  unit.  A  student's  understanding  is 
tested  from  time  to  time  by  presenting  questions 
on  the  screen.  Incorrect  responses  are  remedi¬ 
ated,  while  correct  responses  take  the  student 
along  the  main  path  of  the  lesson. 


The  OMEGA  language  consists  of  approximately 
50  commands,  but  only  a  dozen  or  so  are  required 
for  most  lesson  authoring.  These  commands  are 
divided  into  six  categories,  according  to  func¬ 
tion: 

o  Lesson  exeaution 
o  Instruction 
o  Student  interaction 
o  Lesson  variables 
o  Simulator  communication 
o  Instructor  communication. 

Lesson  Execution:  The  lesson  execution 

commands  serve  two  functions:  they  divide  lessons 
into  logical  units  called  EVENTS,  and  they  provide 
branching  within  a  lesson  that  is  not  student- 
initiated.  These  commands  are  totally  transparent 
to  the  student  at  lesson  run  time,  but  it  is 
primarily  these  commands  that  give  flexibility  and 
power  to  the  language. 

Instruction:  The  commands  that  present 

instruction  to  the  student  at  run  time  either 


display  video  images  and/or  audio  messages  l  rom 
tile  videodisc,  or  they  present  computer  generated 
graphics  that  can  be  overlaid  on  video  graphics. 
As  is  tile  case  with  all  computer  based  instruc¬ 
tional  systems,  each  instructional  message  is 
determined  during  lesson  design.  The  OMEGA 
instructional  delivery  commands  simply  sequence 
tiie  messages  properly. 

Student  Interaction:  Student  interaction 
commands  allow  the  student  to  communicate  with  the 
system.  This  communication  can  take  t lie  term  of 
"go  ahead"  indications,  responses  to  direct 
questions,  or  3D  manipulations,  as  discussed 
above.  Student  responses  are  judged  as  either 
correct,  anticipated  incorrect,  nr  unanticipated. 
The  system  reacts  differently  to  eacli  category  of 
response.  For  both  correct  and  anticipated 
incorrect  responses,  it  proceeds  to  an  place  in 
the  program  that  has  been  specified  in  the 
command.  At  that  place,  the  system  either  advan¬ 
ces  the  student  on  tiirough  the  lesson  or  provides 
remediation  specific  to  the  action  taken. 

Unanticipated  actions  are  incorrect  by 
definition.  Since  thev  have  not  been  anticipated, 
it  is  not  possible  to  provide  specific  remediation 
for  them.  In  such  situations,  the  OMEGA  software 
provides  a  system  generated  message  that  tells  the 
student  what  control  was  moved,  what  position  it 
was  moved  to,  and  what  position  it  was  moved  from. 
This  allows  the  student  to  correct  the  error 
before  attempting  to  continue  through  the  lesson. 

Lesson  Variables:  The  author  can  define  and 
manipulate  variables  using  OMEGA  commands.  These 
variables  can  be  used  for  a  number  of  purposes. 
They  can  be  used  to  keep  track  of  student  errors, 
including  number  and  type.  They  can  count  the 
number  of  times  a  student  exercises  a  procedure; 
this  could  be  used  in  a  situation  where  there  are 
three  different  versions  of  the  same  help  message. 
By  keeping  track  of  how  many  times  the  student  has 
asked  for  help,  the  lesson  can  provide  a  different 
message  each  time.  The  variables  can  also  be  used 
as  the  basis  for  branching  within  a  program. 

Simulator  Communication:  When  dealing  with  a 
3D  simulator,  it  is  frequently  necessary  for  the 
lesson  programs  to  communicate  with  the  simulator 
programs.  Much  of  this  communication  is  done 
automatically  using  the  student  interaction  com¬ 
mands  discussed  above.  There  are  times,  however, 
when  additional  communication  is  required,  either 
to  manipulate  variables  in  the  simulator's  pro¬ 
grams  or  to  determine  the  value  of  those  vari¬ 
ables,  The  simulator  communication  commands  allow 
for  this  additional  interaction  between  the  lesson 
and  the  simulator. 

Instructor  Communication:  The  OMEGA  system 
allows  an  instructor  to  monitor  what  the  student 
is  doing  on  a  separate  cathode  ray  tube  (CRT). 
Alerts  and/or  informative  messages  can  be  incor¬ 
porated  into  the  OMEGA  lessons  to  ensure  thac  the 
instructor  always  knows  what  is  happening. 

All  of  the  OMEGA  commands  are  straightfor¬ 
ward,  regardless  of  the  category  they  are  in. 
Each  command  consists  of  a  meaningful  mnemonic 
followed  by  parameters.  Most  of  the  commands  have 
three  parameters  or  less,  and  the  most  commonly 
used  typically  have  only  one.  The  most  common 
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values  of  the  parameters  are  set  as  defaults  to 
simplify  their  entry  at  edit  time. 

The  syntax  for  organizing  a  lesson  program  is 
also  quite  simple.  A  lesson  is  organized  as  a 
series  of  EVENTS,  which  are  logical  groupings  of 
OMEGA  commands.  The  group  of  commands  in  an  EVENT 
specify  what  can  happen  at  one  particular  time  in 
a  lesson.  Generally  speaking,  the  elements  of  an 
EVENT  include  what  the  student  will  see  and/  or 
hear,  as  well  as  acceptable  student  responses. 
Other  information,  such  s  instructor  prompts, 
historical  remarks,  or  documentation  notations, 
can  also  be  specified  as  required. 

The  Editor 

The  OMEGA  system  uses  a  sophisticated  off- 
the-shelf  word  processing  text  editor,  because  of 
its  power  and  its  simplicity.  It  provides  exten¬ 
sive  edit  time  help  in  the  form  of  menus,  and  the 
author  can  easily  set  (and  reset)  the  amount  of 
help  desired  while  editing.  The  following 
capabilities  are  provided: 

o  Inserting  text  (characters,  complete 
files) 

o  Deleting  text  (characters,  words,  lines, 
groups  of  lines) 

o  Moving  text  (from  single  character  to 
large  blocks  of  text) 

o  Global  corrections 

o  Saving  text  (blocks,  complete  files). 

The  Procedures 

Each  OMEGA  lesson  is  constructed  by  patting  a 
series  of  commands  into  a  computer  file  using  the 
editor.  Four  different  methods  can  be  used  to 
enter  this  code,  depending  on  the  instructional 
requirements  and  the  programming  capabilities  of 
the  author: 

Command :  The  author  can  enter  individual 

commands  simply  by  using  the  computer  keyboard  as 
a  typewriter.  This  option  provides  maximum 
flexibility,  as  the  author  can  group  and  sequence 
commands  in  any  way  desired. 

Template :  Here  the  OMEGA  system  begins  to 

resemble  the  more  traditional  systems,  but  this 
resemblance  is  only  superficial.  Since  certain 
groupings  of  commands  tend  to  occur  more  often 
than  others  in  any  programming  language,  they  can 
be  grouped  together  to  form  a  template.  Specific 
details  may  vary  from  one  specific  grouping  to 
another  of  the  same  type,  but  the  command  struc¬ 
ture  itself  changes  very  little.  For  convenience 
in  editing,  common  OMEGA  command  groupings  have 
been  put  into  individual  files.  Any  of  these 
files  can  be  inserted  into  any  source  code  file  as 
an  intact  unit  simply  by  using  the  "READ”  option 
available  in  the  editor. 

The  standard  groupings  can  be  considered  as 
templates  because  they  provide  a  predetermined 
structure  to  an  individual  EVENT.  However,  they 
are  flexible  templates  since  they  can  be  tailored 
to  individual  situations  by  adding  or  deleting 
commands  as  necessary.  The  commands  provided  in 
the  templates  already  have  their  most  frequently 
used  parameters  filled  in;  parameters  that  change 
frequently  are  left  blank  to  be  completed  at  edit 
time. 


Theoretically,  anv  number  01  template's  can  be 
stored  in  the  the  system’s  mass  memory,  but  we 
usually  limit  the  number  stored  at  any  one  time 
tor  the  sake  of  simplicity.  ll  the  author  sees 
that  the  same  command  structure  will  be  required 
frequently,  he  can  create  a  new  template  that  can 
be  saved,  used,  modified,  and  deleted  without  ever 
leaving  the  lesson  file  being  edited. 

Extended  Temp  late:  As  the  name  implies,  an 
extended  template  is  a  special  case  ol  the  tem¬ 
plate.  Extended  templates  include  more  than  one 
EVENT,  and  can  include  several  hundred.  They 
usually  involve  rather  sophisticated  logic,  and  so 
are  normally  prepared  and  saved  by  authors  with 
extensive  programming  capabilities.  These  tem¬ 
plates  are  used  for  instructional  formats  whose 
logic  always  remains  constant,  but  whose  details 
may  change,  e.g.,  interactive  games  used  for  drill 
and  practice.  Completing  an  extended  template 
requires  only  a  small  amount  of  editing  relative 
to  the  amount  of  lesson  code  generated. 

Module :  A  module  is  distinguished  from  an 
extended  template  in  that  it  is  a  totally  intact 
unit.  It  requires  no  modification  by  the  author. 
Neither  the  logic  nor  the  details  change  in  a 
module.  It  is  always  used  for  the  same  purpose, 
and  it  always  presents  the  same  instruction. 
Modules  are  normally  used  for  hands  on,  interac¬ 
tive  instruction,  where  the  same  set  of  actions  is 
performed  a  number  of  times  in  different  lessons. 
This  feature  represents  a  tremendous  savings  of 
time  and  labor,  since  the  code  for  any  module  can 
be  included  in  any  lesson  once  it  has  been 
produced. 

EVALUATING  OMEGA 

Simplicity 

OMEGA  is  a  rather  simple  system,  since  both 
the  language  and  the  editor  are  easy  to  learn  and 
use.  Though  new  authors  totally  unfamiliar  with 
programming  cannot  begin  productive  work  as  fast 
as  they  could  on  a  traditional  "user  friendly" 
system  ,  they  are  able  to  do  so  within  a  period  of 
about  two  weeks.  Total  proficiency  can  be  gained 
as  quickly  as  with  the  traditional  approach. 

Capability 

OMEGA  has  a  broad  range  of  capabilities. 
Source  code  can  be  infinitely  tailored  to  the 
requirements  of  any  particular  instructional 
circumstance. 

Adaptability 

The  OMEGA  system  was  designed  from  the 
beginning  for  the  most  sophisticated  applications. 
These  include  not  only  traditional  computer 
assisted  instruction  and  interactive  videodisc, 
but  also  interaction  with  a  three  dimensional 
simulator.  For  this  reason,  the  system  can  be 
used  to  teach  any  cognitive  or  hands  on  objective. 

Tolerance  for  Faults /Diagnostics 

As  is  the  case  for  any  system,  errors  in 
command  syntax  (such  as  entering  an  alphanumeric 
character  where  a  number  is  required)  will  cause 
problems  with  OMEGA.  These  errors  are  trapped 
when  source  code  is  compiled,  however,  and  a 
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complete  set  of  diagnostics  helps  the  author 
identify  and  locate  errors  quickly.  The  extensive 
capabilities  for  internal  lesson  documentation 
also  make  lesson  maintenance  a  relatively  simple 

matter. 

Internal  Helps : 

The  editor  provides  selectable  levels  of  help 
to  the  author  at  edit  time.  A  new  author  can  have 
help  displayed  constantly,  and  can  gradually 
reduce  the  amount  available  as  experience  is 
gained . 


This  is  a  major  advantage  of  OMEGA.  The  use 
of  adaptable  templates,  extended  templates,  and 
modules  allows  the  author  to  enter  large  amounts 
of  source  code  very  quickly  and  efficiently. 
Experience  with  the  system  has  shown  that  editing 
is  considerably  faster  than  with  comparable  menu- 
based  systems.  The  most  outstanding  feature  of 
chis  approach  is  that  there  is  no  loss  of  flex¬ 
ibility  in  using  the  templates  since  they  are 
invoked  and  modified  only  as  required. 


Documentation 


The  OMEGA  approach  to  authoring  lessons  for 
computer  based  instructional  systems  is  a  signi¬ 
ficant  improvement  over  traditional  approaches. 
It  is  a  simple  system  to  learn  and  use,  yet  it  has 
all  the  capabilities  required  for  the  most  sophis¬ 
ticated  applications.  It  can  be  used  for  a  wide 
range  of  applications,  including  the  teaching  of 
both  cognitive  and  hands  on  tasks.  Editing 
proceeds  quickly  and  efficiently,  and  various 
levels  of  help  are  available  to  any  author  at  any 
time.  The  system  provides  for  extensive  internal 
lesson  documentation,  and  extensive  diagnostics 
are  available  to  help  the  author  identify,  locate, 
and  correct  errors  in  lesson  source  code. 
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EFFECTIVENESS  OF  MULTI-YEAR  AND  ADVANCE  PROCUREMENT  CONTRACTS 
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ABSTRACT 

Experience  gained  from  the  use  of  these  types  of  contracts  under  the  new  regulations  has 
proven  that,  within  some  restrictions,  they  have  been  beneficial  to  industry  as  well  as  cost 
effective  for  the  Government.  In  a  typical  example,  over  30%  cost  benefit  over  an  annual 
procurement  has  been  realized  in  acquisition  and  early  delivery  of  training  devices.  The 
experience  demonstrates  the  utility  and  adaptability  of  these  regulations  that  can  be  at¬ 
tained  through  aggressive  and  innovative  use.  Additional  changes  and  use  of  the  regulations 
and  uniform  policies  Implementing  the  regulations  would  provide  more  frequent  use  of  these 
procurement  types. 


INTRODUCTION 

Multi-year  and  advance  procurement  contracts 
have  been  available  to  acquisition  and  financial 
managers  for  a  long  time.  They  have  been  infre¬ 
quently  used  because  of  a  reluctance  by  Industry 
to  accept  the  risks  these  contracts  Imposed.  The 
major  obstacles  have  been: 

1)  The  restriction  on  recovery  of  the  non¬ 
recurring  costs  in  the  case  of  cancel¬ 
lation  of  the  out-year  quantities  to  a 
limit  of  $5.0  million. 

2)  The  equal  pricing  of  the  unit  costs  did 
not  permit  reasonable  recovery  of  the 
total  expended  non-recurring  cost  until 
the  final  year  deliveries. 

3)  The  restriction  that  the  cancellation 
celling  Include  only  non-recurring  cost. 

In  addition  to  creating  financial  risk,  these 
features  failed  to  provide  incentives  for  im¬ 
provements  in  capital  investments  which  Increase 
productivity  and  establish  future  economical 
production  bases. 

Within  the  past  few  years  the  Department  of 
Defense  has  revised  the  procurement  directives 
In  an  attempt  to  relieve  these  restrictions. 
Through  the  Acquisition  Improvement  Program,  the 
acquisition  and  financial  managers  have  been  en¬ 
couraged  to  Implement  the  initiatives  and  pro¬ 
vide  Industry  with  the  Incentives  to  Invest  In 
capital  Improvements  and  to  assume  more  risks 
than  previously  dictated  by  good  business  sense. 

The  Defense  Department  Authorization  Act  of 
1982  went  a  long  way  in  liberalizing  the  use  of 
advance  procurement.  It  authorized  multi-year 
contracts  for  use  in  advance  procurement  and 
extended  the  scope  of  advance  procurement  to 
include  not  only  material  and  parts,  but  also 
components  and  economic  order  quantities  of 
subassemblies  and  assemblies  for  out-year  end 
requirements.  With  these  changes,  the  advance 
procurement  can,  to  some  degree,  replace  or  sup¬ 
plement  the  use  of  multi-year  contracts,  thus 
providing  a  means  for  Increasing  productivity 


and  lowering  cost.  As  a  minimum,  these  changes 
provide  the  acquisition  manager  with  a  greater 
variety  of  contracting  and  funding  modes  to 
reach  a  procurement  objective. 

Although  many  articles,  conferences,  and  sem¬ 
inars  have  addressed  the  multi-year  and  advance 
procurement  contracts  on  major  programs,  few  have 
addressed  smaller  programs  (those  not  identified 
by  a  separate  budget  line  item).  This  paper  pro¬ 
vides  an  example  of  the  effectiveness  achieved 
by  the  use  of  these  types  of  contracts  on  smaller 
programs,  specifically  as  applied  to  a  simulator 
procurement. 

I  will  not  identify  the  program  or  the 
actual  dollar  figures  in  this  paper;  however, 
the  example  provided  is  representative  of  one 
small  program.  It  illustrates  the  teamwork 
required  of  Government  and  industry  and  demon¬ 
strates  an  aggressive  pursuit  of  innovation  in 
the  use  of  contracting  modes  to  provide  end 
items  in  a  timely  fashion  within  budget  con¬ 
straints. 

STATEMENT  OF  PROBLEM 

A  procurement  problem  was  created  because 
the  price  in  the  program  years  exceeded  the  con¬ 
straints  of  the  fiscal  year's  budgets  for  an 
annual  contract.  Table  1  depicts  the  problem 
after  months  of  teamwork  and  risk  consideration. 
It  can  be  seen  that  the  total  price  still  did 
not  fall  within  the  total  budget.  In  addition, 
the  first  and  second  years  were  major  problems. 
Coincidentally,  the  shortfall  was  approximately 
the  amount  of  the  start-up  and  non-recurring 
costs. 


ANNUAL  CONTRACTING 

$  x  1M 


F.Y. 

1 

2 

3 

TOTAL 

Item  Qty 

1 

2 

2 

5 

Price 

24 

26 

28 

78 

Budget  (Est.) 

16 

26 

28 

77 

Problem/ShortFall 

(8) 

Table  1 

0 

0 

(8) 

SUMMARY  OF  APPROACH 


An  analysis  was  conducted  to  determine 
whether  this  program  fit  within  the  multi -year 
and  advance  procurement  contract  guidelines. 
Subcontractors  and  vendors  were  contacted  and 
informed  of  our  plan  of  action,  and  their  co¬ 
operation  was  solicited  in  reducing  costs  to  fit 
within  the  budget  profile.  The  results  were 
encouraging  and,  with  the  assumption  of  some 
risk,  provided  the  comparative  summary  shown  in 
Table  2. 


Annual 

Mul  ti  -Year 
And  Advance 

Contracts 

Procurement 

Units 

5 

5 

Price 

$78M 

$70M 

Cancellation  Ceiling 

- 

$12M 

$  Cost  Avoidance 

- 

$  8M 

Over  Annual 

%  Cost  Avoidance 

- 

10% 

Over  Annual 

RISK  RELATED  FACTORS 

RISK 

Requirement  Stability 

Low 

Funding  Stability 

Low 

Configuration  Stabil- 

Low 

ity 

Cost  Avoidance 

Low 

The  cost  avoidance  shown  in  Table  2  is  a 
pure  subtraction  of  MYP  price  from  the  annual 
price.  This  figure  does  not  represent  the  total 
potential  cost  avoidance  benefits  realized  by 
the  Government.  The  use  of  the  MYP,  and  in  par¬ 
ticular  the  advance  procurement,  permits  the 
simulators  to  be  fielded  much  sooner  than  pos¬ 
sible  utilizing  the  annual  contracting  approach. 
This  early  fielding  results  in  cost  avoidances 
attributable  to  the  significantly  lower  costs  of 
aviator  training  utilizing  simulators  as  com¬ 
pared  to  an  "aircraft  only"  approach.  The 
amount  of  these  cost  avoidances  is  substantially 
dependent  upon  how  much  the  delivery  schedule 
can  be  improved.  In  this  case  history,  the 
overall  schedule  improvement  provided  72  months 
of  earlier  simulator  delivery  with  respect  to 
annual  procurement  for  all  5  devices  (see  Figure 
1). 


Table  2 


ANALYSIS  OF  RESULTS 

The  price  reduction  was  for  the  most  part 
accomplished  through  the  use  of  economic  order 
quantities.  Although  this  did  not  get  us  to  our 
goal,  the  use  of  EPA  clauses,  negotiations,  and 
the  stability  of  the  program  as  evidenced  by  the 
risk  factors  convinced  all  parties  that  addi¬ 
tional  cost  risks  could  be  accepted.  The 
resulting  program  profile.  Illustrated  in 
Table  3,  closely  matched  the  budget  profile. 


MULTI-YEAR  AND  ADVANCE  PROCUREMENT 

$  x  1M 


F.Y, 

1 

2 

3 

TOTAL 

Item  Qty 

1 

2 

2 

5 

Price 

14 

28 

28 

70 

Budget 

16 

26 

28 

70 

Problem/Short  Fall 

2 

(2) 

0 

0 

Table  3 


ANNUAL  - 

DELIVERY  V 


Figure  1  SCHEDULE  ADVANTAGE  OF  MULTI-YEAR 
PROCUREMENT 


The  average  cost  of  aircraft  operation  in 
1982  dollars  for  the  example  simulator  above  is 
$2, 300/hr.  This  figure  compares  to  an  average 
simulator  operating  cost  of  $290/hr.  Simulator 
operation  may  be  conservatively  estimated  at 
2,000  hours  per  year. 

On  the  basis  of  these  figures,  an  additional 
cost  avoidance  of  approximately  $24.0  million 
was  achieved.  This  cost  avoidance  amount  is 
30.7%  of  the  annual  contract  program  pricel 
Results  of  this  magnitude  merit  serious  con¬ 
sideration  and  are  well  worth  the  earlier  starts 
provided  by  the  mixture  of  contracting  modes. 


CONCLUSION 


To  the  contractor  and  subcontractors/ 
vendors,  this  method  of  contracting  provided  a 
more  competitive  procurement,  enabled  consider¬ 
ation  for  additional  capital  equipment,  smoothing 
of  the  workload,  and  better  application  of  learn¬ 
ing.  The  result  of  the  use  of  these  contracting 
modes  was  a  program  that  fit  within  the  budget 
profile  and  produced  a  significant  cost 
avoidance. 

This  program  illustrates  the  possible  bene¬ 
fits  that  can  be  attained  by  innovative  use  of 
contracting  modes.  The  teamwork  involved  in 
solving  a  funding  problem  heightens  the  aware¬ 
ness  of  all  parties  with  regard  to  the  amount  of 
work  and  the  acceptable  risks  associated  with 
providing  military  end  items  at  a  more  afford¬ 
able  cost.  More  can  probably  be  done  in  the  use 
of  the  DAR  1-322  changes,  such  as  including  some 
recurring  costs  in  the  cancellation  ceiling. 

There  are  advantages  to  the  Government  and 
industry  in  the  use  of  these  types  of  contract¬ 
ing  modes.  As  has  been  touched  on,  while  MYP 
has  come  a  long  way,  there  are  still  problems 
and  constraints  on  its  use  which  preclude  both 
Government  and  industry  from  receiving  full 
benefits.  Under  current  rules,  MYP  cannot  be 
used  for  commercial  items.  The  budgeting, 
appropriation,  and  funding  process  is  complex 
and  unwieldy.  The  need  to  provide  up-front 
funding  of  recurring  cost  items  purchased  for 
future  year  requirements  pits  a  MYP  against 
other  urgent  and  needed  defense  procurements. 

The  practice  of  requiring  two  full  cost  pro¬ 
posals,  for  comparison  purposes,  one  for  a  MYP 
and  one  for  an  annual  buy,  adds  significantly  to 
contractor  expenses,  is  completely  at  odds  with 
indirect  cost  cutting  efforts  and  is  unnecessary 
once  a  program  is  judged  to  fit  an  MYP  profile. 


In  general,  only  procurement  costs  are  looked 
at  to  judge  MYP  savings,  but  as  shown  above, 
earlier  availability,  at  least  in  the  case  of 
simulation  equipment,  has  a  dramatic  impact  on 
these  savings  and  should  be  considered. 

President  Reagan  commissioned  a  Private 
Sector  Survey  on  Cost  Control  on  June  30,  1982 
(The  Grace  Commisson).  Thirty-six  task  forces 
were  appointed  by  the  Commission,  one  of  which 
covered  Procurement/Contracts/ Inventory  Manage¬ 
ment.  In  its  report  dated  June  13,  1983,  this 
task  force  made  57  recommendations,  five  of 
which  specifically  dealt  with  Multi-Year  Con¬ 
tracting  (Recommendations  PROC  4-1  through  4-5). 
It  is  the  contention  of  this  task  force  that  the 
use  of  multi-year  contractings  would  save  almost 
3.5  billion  dollars  in  just  a  three-year  period 
and  this  is  only  based  on  estimates  of  initial 
procurement  expense. 

The  challenge  is  there  and  it  is  up  to  all 
of  us  to  accept  the  challenge  and  improve  on  cost 
and  productivity  and  to  continue  to  pursue  mutu¬ 
ally  acceptable  techniques  for  providing  needed 
items  at  an  affordable  cost. 
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AiiCTiACT' 

"Concur  li  ncy"  is  the  v*>i  a  being  used  to  disci  ibe  the  situation  when  a  simulator  ot  other 
aircrew  training  devices  an.  m|uunl  loi  Delivery  at  the  some  t  i:u».  a::  the  new  aitcialt  it  will 
support.  II  tiaditional  ocquiaitrun  ajrpioaches  are  applied  to  con  out  tent  ai  ret  aft  and  sisu- 
lation  programs,  it  is  piactically  lmiossible,  in  .many  cases,  to  deliver  a  fully  capable 
aircrew  training  device  anywiiere  neat  the  Initial  (^relational  Cafjability  (1UC)  ot  the  aii- 
cratt.  This  is  especially  true  when  dealing  with  aircrew  trainers  Lot  a  complex  tactical 
or  strategic  weaixm  system.  Using  the  li—  1U  Simulator  System  program  as  an  example,  tins 
paper  discusses  the  risks  and  management  challenges  involved  with  concurrency  and  an  in¬ 
novative  acquisition  strategy  designed  to  ensure  the  availability  ot  aircrew  training 
devices  at  or  before  the  aircraft  IOC.  Included  in  this  strategy  are:  1)  j  ne-w  approach 
to  preparation  ot  the  request  Cor  proposals  documentation,  2)  a  competitive  preliminary 
design  effort,  3)  methods  for  dealing  with  the  acquisition  of  simulator  design  data, 

4)  the  concept  of  providing  the  user  a  limited  (interim)  training  capability  early  in  the 
program,  5)  management  of  a  configuration  baseline  which  evolves  along  with  the  simulator 
design,  and  6)  retrofit/updato  of  all  delivered  devices  to  the  final  aircraft  configuration. 

IfmtODUCl'ION 


The  simulator  acquisition  process  is  changing. 
The  changes  have  ccme  about  for  several  different 
reason...  One  reason  is  the  fact  that  simulators 
have  steadily  grown  in  complexity  along  with  the 
technology  that  supports  them.  Another  reason  is 
that  simulator  users  have  demanded  a  higher  level 
of  simulator  performance  in  order  to  support 
training  programs  with  fewer  actual  aircraft 
flight  hours.  However,  the  biggest  changes  in 
simulator  acquisition  strategies  have  cane  about 
because-  of  aircraft/simulator  concurrency.  "Con¬ 
currency"  is  the  term  being  used  to  describe  the 
situation  when  simulators  or  other  aircrew  train¬ 
ing  devices  are  required  for  delivery  at  the  same 
time  as  the  new  aircraft  it  will  support. 

Concurrency  has  brought  with  it  new  challenges 
for  the  simulator  procurer.  No  longer  can  one 
wait  until  flight  test  or  even  the  initial  air¬ 
craft  production  run  is  complete  before  committing 
to  a  simulator  acquisition  program.  The  complex¬ 
ity  ot  most  of  the  full  mission  simulators  being 
acquired  by  the  Air  Force  today  has  resulted  in 
simulator  development  programs  which  are  not  much 
shorter  than  the  aircraft  development  programs 
themselves.  Therefore  simulator  development  pro¬ 
grams,  in  order  to  produce  and  deliver  trainers  at 
or  before  the  aircraft  IOC,  must  be  started  very 
early  in  the  aircraft  development  process.  Start¬ 
ing  a  simulator  program  this  early,  relative  to 
the  aircraft  program,  carries  with  it  some  amount 
of  risk.  Most,  if  not  all,  of  the  risk  is  related 
to  the  inmaturity  of  design  data  and  the  un¬ 
certainty  regarding  the  evolving  aircraft  config¬ 
uration.  In  order  to  control  these  risks,  new 
acquisition  strategies  are  required.  The  B-1B 
Simulator  System  program  is  one  example  of  a  con¬ 
current  simulator  development  program.  This 
program  is  applying  several  new  concepts  to  the 
Air  Force  simulator  acquisition  process;  a  new 
approach  to  constructing  the  Request  for  Proposals 
(KFP),  a  competitive  preliminary  design  effort,  an 
integral  retrofit  (update  process)  and  providing 
the  user  a  limited  early  training  capability  are 
the  key  elements  of  the  B-1B  Simulator  System 


aexjusition  strategy. 

BACKOROUND 

The  design,  performance  and  test  criteria  lor 
simulators  is  based  on  aircraft  data  (test  reports, 
drawings,  technical  orders,  technical  reports, 
etc.).  This  data  defines  the  design,  (rerformance, 
and  operating  characteristics  of  the  aircraft  and 
aircraft  systems.  The  degree  to  which  the  simu¬ 
lator  will  be  representative  of  the  aircraft 
depends  upon  how  well  the  data  package  describes 
the  aircraft.  The  data's  description  of  the  air¬ 
craft  depends  upon  the  point  in  the  aircraft 
development  program  that  the  data  is  baselined  and 
how  much  the  data  base  is  updated  to  represent  thr 
aircraft's  production  baseline. 

The  aircraft  design  is  dynamic  dui ing  the 
development  process.  There  are,  typically,  throe 
points  in  the  aircraft  program  where  the  design 
becomes  baselined.  These  points  are:  the  Full 
Scale  Development  (FSD)  Critical  Design  Review 
(CDR) ,  the  start  of  flight  test,  and  the  produc¬ 
tion  configuration  baseline.  In  most  current 
simulator  programs,  the  data  baseline  occurs  Ijc- 
tween  the  start  of  flight  test  and  production 
(Figure  I).  The  aircraft  definition  of  the  simu¬ 
lator  is  usually  the  start  of  flight  test  with 
some  updating  to  the  production  configuration.  As 
a  result,  the  Engineering  Change  Order  (ECO) 
budget  for  simulator  programs  is  normally  struc¬ 
tured  to  update  the  simulators  to  the  eventual 
production  configuration. 

This  typical  simulator  development  approach  in 
which  the  data  baseline  dc))ends  upon  the  flight 
test  data  baseline  of  the  aircraft  (with  some 
updating  to  the  production  baseline)  minimizes 
cost  risk  associated  with  the  simulator  updates, 
but  delays  simulator  availability  until  late  in 
the  aircraft  program  (usually  well  after  initial 
aircraft  availability  and  the  aircraft  Initial 
Operational  Caj>ability  (IOC)).  The  more  optimal 
or  mature  the  data  (Package,  in  terms  of 
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PRESENT  SIMULATOR  PROGRAMS 
(AIRCRAFT  VS  SIMULATOR) 


AIRCRAFT  PROGRAM 
FSO  CA 

PDR  COR  TEST  &  EVALUATION  PRODUCTION 


DESIGN  CHANGES 


SIMULATOR  PROGRAM 


CA  PDR  CDR  TEST  PRODUCTION 

FIGURE  1 


completeness  and  currency,  the  later  it  becomes 
available  and  the  later  the  simulator  will  be 
delivered  in  relationship  to  the  aircraft.  The 
B-l  simulator  projram  has  been  structured  to  gain 
concurrency  with  the  aircraft  program  (to  the 
degree  possible)  but  with  acceptable  risk  associ¬ 
ated  with  the  changing  aircraft  baseline  and 
concurrent  aircraft  and  simulator  developments. 

The  B-1B  simulator  program  will  have  the  design 
data  freeze  dates  tentatively  established  based 
upon  the  aircraft  software  Physical  Configuration 
Audit  (PCA)  baseline  (for  Prototype  and  Lot  1 
production  simulators)  and  completion  of  flight 
test  (for  Lot  2  production  simulators)  (Figure  2). 
These  baseline  or  freeze  dates  seem  most  appropri¬ 
ate  when  viewed  from  the  perspective  of  the 
simulator  program  not  being  initiated  until  almost 
a  full  year  after  the  aircraft  contract  go-ahead 
and  the  fact  that  the  B-1B  aircraft  program  itself 
has  concurrent  development  and  production  activ¬ 
ities. 

B— IB  SIMULATOR  SYSTEM 
Program  Overview 

The  B-1B  simulator  acquisition  strategy  is 
based  upon  a  two-phase  program  intended  to  provide 
a  training  capability  as  close  to  the  aircraft  IOC 
as  possible.  Phase  1  is  a  competitive  effort  by 
two  contractors  to  complete  the  system  definition 
and  the  FSD  effort  through  the  Preliminary  Design 
Review  (PDR)  milestone.  The  Phase  1  contractor 
activities  include: 

a.  Writing  detailed  performance  specifica¬ 
tions. 

b.  Writing  vendor  and  subcontractor  work 
packages. 

c.  Formulating  contractual  agreements 
covering  data,  parts,  and  services  with  each  of 
the  B-1B  weapon  system  associate  contractors. 

d.  Conducting  trade  studies  in  design  and 
logistics  (to  identify  and  reduce  cost  drivers). 

e.  Completing  the  simulator  system  design  to 
the  PDR  level. 


f.  Conducting  detailed  cost ,  schedule  and 
technical  planning  for  Phase  11. 

Phase  11  of  the  program  will  include  comple¬ 
tion  of  FSD  and  production  of  the  simulators. 
During  Phase  11,  five  Weapon  System  Trainers  (WST), 
two  Mission  Trainers  (MT)  and  a  Software  Support 
Center  (SSC)  will  be  developed,  fabricated  and 
delivered  to  the  Strategic  Air  Ccmmand. 

The  keenest  for  Proixisals 

Given  concurrency  and  the  initiation  of  the 
B— IB  Simulator  System  program  nearly  a  full  year 
after  the  B-1B  aircraft  go-ahead,  it  was  necessary 
to  find  a  way  to  condense  the  front  end  of  the 
acquisition  process  referred  to  as  the  RFP  genera¬ 
tion  phase. 

The  Requests  tor  Proposals  (RFPs)  for  Air 
Force  simulator  acquisitions  are  typically  com¬ 
prised  of  a  Statement  of  Work  (SOW) ,  a  Contract 
Data  Requirements  List  (CDRL) ,  the  model  contract 
and  one  or  more  Prime  Item  Development  Sjxxrifica- 
tions  (PIDS) . 

Speci f icat ions .  The  PIDS  typically  define 
the  detailed  performance  of  the  simulator  or  major 
simulator  subsystem  being  acquiree! .  When  the 
simulation  device  being  acquired  is  to  represent 
an  aircraft  or  aircraft  subsystem  (o.g.,  radar) 
which  has  been  in  the  inventory  for  seme  time  or 
at  least  has  completed  developmental  flight  test, 
the  writing  of  the  PIDS  is  relatively  straight¬ 
forward;  actual  performance  of  the  "to  be  simu¬ 
lated"  system  is  documented  by  both  design  and 
performance  specifications  and  some  flight  test 
data  is  normally  available.  In  the  concurrent 
aircraft/simulator  design  situation,  actual  system 
performance  data  is,  at  best,  speculative  when  the 
simulator  RFP  needs  to  bo  written.  For  the  B-1B 
Simulator  System  program,  the  solution  was  to 
write  a  system  level  specification  which  relates 
the  major  system  components  to  be  acquired  and 
their  losic  functional  characteristics.  The  prime 
item  devourment  speci  f  icat  ions  will  Ire  written  !>y 
the  canpcting  contractors  during  Phase  1  of  the 
program.  The  com) ret rng  contractors  will  develop 
separate  prime  item  specifications  for  the  WSTs, 
the  Mrs,  and  the  Software  Sup[»rt  Center.  Those 
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specifications  will  be  written  based  not  only  on 
the  system  specification  issued  with  the  Phase  1 
RFP,  but  also  on  the  user's  (Strategic  Air  Com¬ 
mand)  stated  training  concepts  and  concept  of 
employment  of  the  trainers  within  the  overall 
B-1B  training  curriculum. 

The  advantages  of  having  the  contractor  write 
the  prime  item  specifications  are  three- fold:  1) 
It  normally  takes  the  Air  Force  engineers  six  to 
nine  months  to  generate  prime  item  spec ifications 
for  simulators  as  complex  as  the  B-1B  Simulator 
System.  This  presupp6ses  that  the  essential  air¬ 
craft  or  subsystem  performance  data  is  available 
at  the  time  the  task  is  undertaken.  Hence,  by 
having  the  contractors  generate  the  detailed 
specifications  after  the  contract  is  underway, 
several  months  of  front-end  lead  time  can  be 
eliminated.  In  addition,  the  Air  Force's  specifi¬ 
cation  writing  team  is  normally  rather  small.  The 
contractor  can  usually  devote  more  manpower  to  the 
task  and,  therefore,  complete  it  in  a  shorter 
period  of  time.  2)  data  on  the  various  aircraft 
subsystems  usually  becomes  available  in  a  scejuen- 
tial  fashion  as  the  aircraft  develojment  proceeds. 
Therefore,  the  simulator  contractor  can  acquire 
aircraft  design  specifications  and  performance 
data,  write  the  PIDS  and  create  the  preliminary 
design  for  the  simulator  on  a  piecewise  basis. 

The  complete  prime  item  specifications,  then,  can 
tie  assembled  as  tin  contract  (and  the  preliminary 
design  effort)  progresses.  1)  When  a  new  weajxjn 


system  is  in  its  early  stages  of  dsveloimont,  the 
user  is  not  able  to  provide  details  of  exactly  how 
the  simulator  will  lx  used  in  the  training  curric¬ 
ulum.  Based  on  exper ieneo,  the  user  is  capabl-  of 
describing  the  general  types  of  device;#  that  will 
Lx-  needed  to  train  the  aircrews,  but  specific 
training  device  characteristics  cannot  U  proviso 
until  the  design  of  the  weapon  system  ana  its  sulr- 
systems  reaches  some  level  of  maturity.  When  tin 
weapon  system  design  matures  sufficiently  to  allot, 
the  user  to  identify  the  various  3[jooif  ic  aircrew 
tasks,  the  user  can  then  make  some  definitive 
statements  regarding  how  the  training  devices  will 
be-  employed.  In  the  B-1B  Simulator  System  program 
the  training  concept  and  training  task  analysis 
data  have  lieen  provided  to  the  contractors  shoitlt 
alter  Phase  1  contract  award.  At  that  time,  all 
of  the  airframe  ana  major  subsystem  critical  hi  sis 
reviews  were  completed  and  the  majority  <>>  tin  ait 
crew  training  tasks  w.  t  e  ide-r.t  i ;  iable  . 

In  the  two— phased  L5-1B  Simulator  System  acqui¬ 
sition  projram,  tb  Pt  Lik  lb  r,  l> -ve  I05 r> fit  Sp-ci- 
tications  generated  by  the  contractors  iut ing 
Phase  1  will  become  the  local  punt  o'  t:.>  it  pi  <  >- 
[osals  for  Phase  11.  During  th-  preliminary  d.  si 
review,  which  essential  ly  oompl*  t<  s.  Pi, a:  •  1  jet  iv- 
ity,  the  simulator  designs-  will  :x  •  valuaud  in 
light  of  the  prime  item  sjx-cif  rcations.  Th-  s< 
sixsci  I  ications  will  then  lx -cor.*-  th<  conti  actual 
basis  lot  simulator  tx-t  lormuno  111  i'h.e  -  11. 
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it  was  necessary  to  give  the  Phase  1  oil.  uu  j  In  the-  concurrent  uircral t/simulutor  dev-  i  — 

some  insi  ;hl  into  the  «ns  envi.-;i-*v-d  tot  ilrase  :s:nt  situation  of  the  B-1B,  having  th-  Simula:  n 

11.  Accordingly,  an  annex  to  Ux  Phase  1  SU\  contractor  bo  responsible  lot  obtuinrn  i  Ur  r  i  n 

outlines  tin.-  major  tasks  planned  tor  Phase  11.  criteria  is  the  only  practical  approach.  Sp  •  m  ir. 

While  written  in  SOW  language  and  tot::, at,  this  obtain iny  the  basic  design  data  ana  timely  uuiai-  s 

annex  is  ;■  r ov ideb  "tot  information  only"  and  is  thereto  is  of  luramount  hiijxjt tance .  In  the  can¬ 
not  contractually  binding  during  Phase  1.  In  cui  tent  uevc-lopnent  scenario,  the  simulator  son- 

aduition  to  the  Phase  11  insights  this  annex  tractor  must  be  capable  of  obtaining  preliminary 

afforseu  the  offerors,  it  also  provides  the  pro-  enyinceriny  data  concern iny  p>tentiul  aiicralt 

curing  agency  a  certain  amount  of  flexibility  and  Engineering  Change  Proposals*  (bCP)  ix-iore  the  uii- 

additional  time  to  define  the  detailed  Phase  11  craft  ECPs  are  formally  suiisi  tted  to  tb-  Air  hue.-. 

'Mark  requirements.  Given  the  concurrent  evalua-  This  will  allow  the  simulator  contractor  to  posur- 

tion  of  the  weapon  system  to  be-  simulated,  the  simulator  design  change  impact  studies  in  parallel 

simulator  procuring  agency  is  afiorded  more  time  with  the  generation  of  the-  aircraft  ECP.  Hence-, 

to  finalize  development  and  production  details.  when  the  aircraft  UCP  is  considered  lot  incorpr- 

In  tact,  it  allows  the  Air  Force  to  factor  in-  ration  into  the  aircraft,  tlx-  potential  impact  of 

formation  gained  during  Phase  1  source  selection  the  change  on  the  simulator  can  be  thoroughly 

and  the  initial  part  of  Phase  1  contractual  activ-  evaluated  by  the  Air  Force  at  the  same  time."  If 

ity  into  the  Phase  11  SCW.  It  is  believed  that  the  change  data  were  not  available  to  the  simulator 

the  result  will  be  a  much  more  accurate  and  del  in-  contractor  until  alter  the  FCP  was  formally  u:>- 

itive  document.  Also,  since  the  contractors  are  proved,  the  associated  change  to  the  simulator 

encouraged  to  refine  the  government’s  overall  would  most  often  occur  well  after  the  aircraft 

program  planning  schedules  during  Phase  1,  the  change, 

realism  of  the  Phase  11  SCW  can  be  enhanced  by 

incorporating  the  contractor's  relevant  comments.  Configuration  Management  and  Update 


The  Competitive  Design  Effort 


As  outlined  earlier.  Phase  1  of  the  B-1B  Simu¬ 
lator  System  program  is  a  competitive  design 
effort  by  two  contractors.  The  competitive  Phase 
1  design  effort  will  ensure  that  the  simulators  to 
be  delivered  during  Phase  11  will  provide  an 
optimal  mix  of  performance,  fidelity  and  instruc¬ 
tional  features.  Equally  as  important  is  the  fact 
that  the  cost  of  the  development  and  production  of 
the  simulators  (Phase  11)  will  be  bid  on  a  com¬ 
petitive  basis.  Hence,  the  delivered  simulators 
should  provide  the  best  possible  training  capa¬ 
bility  at  the  lowest  possible  c  at. 

Design  Data  Acquisition 

The  topic  of  who  is  or  should  be  responsible 
lor  obtaining  the  simulator  design  data  is  always 
sharply  debated.  The  sides  are  usually  clearly 
drawn.  It  upp.-ars  that  the  simulator  manuiac- 
turers  think  the  Air  Force  should  collect  and 
provide  the  data  to  the-  contractor,  yet  the-  Ait 
Force  many  times  structures  contracts  to  handle- 
design  data  or  design  criteria  by  having  the-  simu¬ 
lator  contractor  obtain  the  data  directly  from  the 
airframe-  and  avionics  contractors.  The  reasoning 
on  loth  sides  of  the  debate  is  sound;  the  con¬ 
tractor  would  like-  to  avoid  the  acquisition  cost 
of  the  data  and  the  Air  Force  would  like  to  "stay 
out  of  the  data  business".  Also,  it  is  generally 
held  that  the  organization  which  collects  the  data 
is  ultimately  re-si Jonsible  lor  its  completeness 
and  accuracy.  Hence,  one  more  reason  to  shun  the 
role  of  data  collector. 


In  reality,  the  responsibility  lor  obtaining 
simulator  design  criteria  lx-st  lies  with  the  simu¬ 
lator  developer .  The-  developer  knows  first-hand 
exactly  what  amount  and  type:  ol  data  are  repaired 


The  non-concurrent  simulator  program  normally 
has  a  single  design  criteria  freeze  date  and  a 
single  CDR.  All  changes  to  design  criteria  occur¬ 
ring  after  the-  freeze  date,  whether  representing 
more  mature  data  or  aircraft  design  changes,  result 
in  "cost"  ICPs.  In  a  concurrent  simulator  develo[>- 
ment  program,  many  changes  in  design  criteria  can 
be  expected  throughout  the  program.  Processing  a 
cost  ECP  lor  every  design  criteria  change  would 
present  a  configuration  nightmare  and  an  unaccept¬ 
able  cost  risk.  In  the-  B-1B  Simulator  System  pro¬ 
gram,  multiple  freeze  dates  and  incremental  CDRs 
are  planned.  An  initial  freeze  date  and  CDR  will 
cover  the  prototyi>e  WST  and  the  first  production 
lot  (two  WST's,  an  Mr  and  th-  -  Software  Suppirt 
Center).  A  second  freeze  date  and  a  delta  CDR  will 
cover  the  second  production  lot  (2  WSTs  anti  an  MI  )  . 
/Ml  configuration  uplate  activity  required  to  bring 
the  prototype  WST  and  the  last  1  devices  up  to  the 
production  aircraft  design  baseline  will  b>-  part  ol 
the  initial  Phase  11  contract  cost.  This  integral 
uplate  approach  reduces  the  cost  risk  associated 
with  attempting  to  maintain  aircraft/simulator 
concurrency. 


Training  Capability 


Every  attempt  was  made  to  structure  a  program 
to  deliver  B-1B  simulators  at  or  before  the  air¬ 
craft  IOC.  Due  to  a  late  start  of  the  Simula tot 
program  relative-  to  the  aircral  t  projiam  a::  well  as 
limited  early  availability  ol  ot tensive  and  defen¬ 
sive  avionics  -lata,  delivery  ol  the  Inst  WST  is 
not  passible  until  approximately  one  y<-at  alter  the 
aircraft  IOC.  In  order  to  provide  on  earlier 
training  ca|xability#  a  concept  called  the  "early 
1  light  station"  was  develop-d.  Since  a  large  pn- 
tion  of  the  B— IB  aircralt  development  is  in  the 
avionics  area,  the  design  -data  lor  the  WST  avionic: 
stations  (ol  tensive  systems  ol  lio-r  and  dciensivi 
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systems  officer  positions)  is  the  pacing  item  in 
the  WST  design,  development  and  delivery  sched¬ 
ules.  However,  due  to  extensive  flight  testing 
of  tire  existing  B-1A  aircraft,  relatively  mature 
B-1B  flight  performance  (aerodynamics  and  pro¬ 
pulsion)  data  will  be  available  early  in  the  simu¬ 
lator  program  and  the  development  and  availability 
of  a  simulator  flight  station  (pilot  and  copilot 
positions)  is  possible  at  or  slightly  before  the 
aircraft  IOC.  The  early  flight  station  is  ex¬ 
pected  to  be  essentially  the  same  as  the  flight 
station  portion  of  the  WSTs.  The  early  flight 
station  will  be  made  available  for  SAC  aircrew 
training  until  the  prototype  WST  becomes  ready  for 
training.  At  that  time,  the  early  flight  station 
will  be  deactivated  and  its  residual  hardware 
assets  applied  to  one  of  the  production  WSTs. 

CONCLUSIONS 

Applying  traditional  acquisition  strategies 
to  the  problem  of  aircraft/simulator  concurrency 
results  in  excessive  cost  and  performance  risks. 
New  acquisition  strategies  such  as  those  being 
applied  to  the  B-1B  Simulator  System  program  are 
required  ir  order  to  control  risks  and  assure  the 
timely  delivery  of  training  devices  to  the  user. 
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To  effectively  manage  a  low  quantity,  high  technology  trainer  development  program,  the 
program  management  team  must  consider  a  variety  of  trade-offs  during  the  development  cycle. 
These  trade-offs  stem  from  the  fact  that  a  limited  production  trainer  is  neither  a 
prototype  nor  a  production  line  unit.  This  paper  presents  the  Issues  and  trade-offs  which 
should  be  addressed  by  the  program  management  team  prior  to  and  during  the  trainer 
development  program. 


INTRODUCTION 

We  in  the  trainer  development  community 
are  generally  faced  with  developing  a  high 
technology  trainer  that  has  a  small  number  of 
follow-on  production  units.  This  situation 
presents  an  interesting  management  problem.  The 
quantity  of  follow-on  units  is  not  large  enough 
to  justify  setting  up  the  program  and  running  it 
like  a  full  scale  production  job,  but  the 
quantity  of  follow-on  units  and  the  requirement 
to  produce  production  quality  end  items 
prohibits  the  full  use  of  prototyping 
techniques . 

A  successful  trainer  development  program 
must  draw  upon  the  processes  and  management 
techniques  of  both  production  and  prototyping. 
This  paper  presents  the  issues  and  trade-offs 
which  should  be  addressed  by  the  program 
management  team  prior  to  and  during  the  trainer 
development  program.  The  main  items  addressed 


1.  Configuration  Control  -  Maintaining 
configuration  control  throughout  the  development 
and  production  cycles. 

2.  Design  -  Designing  to  cost  with  the 
balance  of  non-recurring  and  recurring  costs. 

3.  Production  -  Deciding  on  what  to 
build  yourself,  what  to  subcontract  and  when  to 
place  procurement  orders. 

A.  Testing  -  Deciding  on  the  level 
(board,  sub-system,  system)  of  testing  to  be 
performed  and  whether  engineering  or  manu¬ 
facturing  should  perform  this  testing. 

5.  Support  -  Developing  a  good  long  term 
support  program  within  the  commercial  grade 
trainer  budget  and  schedule. 

CONFIGURATION  CONTROL 

Configuration  control  is  important 
regardless  of  the  number  of  trainer  units  that 
are  to  be  built.  Even  when  a  prototype  device 
is  being  developed,  it  is  important  to  document 
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the  configuration  of  the  device  for  several 
reasons.  First  and  foremost  is  the  fact  that  it 
is  necessary  to  maintain  enough  configuration 
control  in  order  to  know  what  you  have  done. 
Second,  it  is  important  to  maintain  enough 
configuration  control  in  order  to  keep  the 
prototype  device  working  during  its  life  cycle. 

For  a  full  scale  production  program, 
configuration  control  is  even  more  important 
because  it  has  a  significant  impact  on  the  life 
cycle  cost.  A  good  configuration  control 
program  will  keep  all  the  production  units  as 
identical  as  possible  and  maintain  an  accurate 
file  of  all  differences.  The  benefit  of  this 
program  will  be  that  common  spares,  training, 
updates,  etc.  can  be  used  to  support  all  the 
trainers,  rather  than  having  a  separate  life 
cycle  support  program  for  each  trainer.  Special 
attention  to  the  configuration  control  program 
must  be  paid  to  the  first  development  unit. 
During  the  development  phase  where  the  designers 
are  implementing  many  changes  to  make  their 
conceptual  design  a  reality,  it  is  easy  for  the 
actual  configuration  of  the  developi  »nt  unit  to 
be  lost.  This  has  proven  to  be  very  costly  to 
many  contractors  when  they  release  to  build  the 
follow-on  production  units  and  end  up  making 
another  batch  of  prototype  units  which  must  be 
made  to  work. 

A  special  problem  that  we  in  the  training 
community  have  with  our  limited  production, 
design  to  cost,  trainers  is  the  use  of  commer¬ 
cially  supplied  equipment,  i.e.  computers,  power 
supplies,  etc.  It  is  difficult  to  maintain 
configuration  control  during  a  long  production 
schedule  in  which  only  a  few  trainers  are 
produced  every  year.  Commercial  equipment 
configuration  changes  at  a  very  rapid  rate. 
What  a  contractor  can  purchase  for  one 
production  lot  may  not  be  the  same  for  the  next 
production  lot.  This  topic  and  how  to  deal  with 
It  is  a  paper  all  in  itself.  Let  it  suffice  to 
say  that  we  do  the  best  we  can. 

Configuration  control  objectives  differ 
depending  on  whether  a  contractor  is  building  a 
prototype,  full  production  or  limited  production 
trainer.  Table  1  presents  a  comparison  of  these 
objectives . 


TABLE  1. 


CONFIGURATION  CONTROL  OBJECTIVES 


PROTOTYPE  OBJECTIVES 

1.  Maintain  enough  control  In 
order  to  know  what  you 
have  done. 

2.  Maintain  enough  control  in 
order  to  keep  the  device 
working  with  an  engineer¬ 
ing  staff. 


FULL  PRODUCT  ION  OBJECTIVES 

1.  Maintain  enough  control  In 
order  to  have  all  devices 
as  identical  as  possible. 

2.  Maintain  enough  control  so 
that  one  set  of  documenta¬ 
tion,  spares  and  training 
courses  will  suffice  to 
support  all  devices  during 
their  life  cycle. 


LIMITED  PRODUCT ION  OBJECTIVES 

1.  Same  as  "full  production" 
objectives  with  the 
exception  of  commerc ial  1  v 
supplied  equipment  (l.e. 
computers,  etc.)  which  we 
do  the  best  we  can. 


DESIGN 

The  major  objective  for  the  design  of  a 
limited  production  trainer  Is  designing  to  cost 
with  a  balance  of  non-recurring  and  recurring 
costs.  This  objective  is  a  compromise  between 
the  design  objectives  of  a  prototype  device  and 
a  full  production  device.  Prototype  or  one  of  a 
kind  devices  generally  make  use  of  what  is 
readily  available  in  order  to  demonstrate  a 
capability  quickly  and  reduce  non-recurring 
costs.  The  tendency  is  to  buy  hardware  or 
software  rather  than  develop  new  software.  On  a 


full  production  program,  it  Is  generally  more 
advantageous  to  design  new  hardware  and  software 
in  order  to  reduce  the  recurring  costs.  The  key 
to  a  successful  limited  production  trainer 
program  is  to  identify  the  components  of  the 
trainer  which  may  satisfy  the  requirements  of  a 
full  production  program  or  a  prototype  program. 
Once  these  components  are  identified,  the 
appropriate  design  objectives  can  be  applied  to 
provide  an  overall  lower  program  cost.  Table  2 
provides  a  comparison  of  the  design  objectives 
of  a  prototype,  full  production  and  limited 
production  trainer. 


PROTOTYPE  OBJECTIVES 


TABLE  2.  DESIGN  OBJECTIVE 

FULL  PRODUCTION  OBJECTIVES  LIMITED  PRODUCTION  OBJECTIVES 


1.  Minimize  non-recurring 
costs. 

2.  Use  available  hardware 

3.  Emphasize  purchased 
hardware/software  vs. 
software  development. 


1.  Minimize  recurring  costs. 

2.  Develop  less  expensive 
hardware. 

3.  Emphasize  software 
development  vs.  purchased 
hardware/ software. 


1.  Balance  of  non-recurring 
and  recurring  costs. 

2.  Attempt  to  use  common 
hardware  and  software 
across  many  different 
types  of  trainers. 


PRODUCTION 

During  the  production  phase  of  a  limited 
production  trainer,  the  program  team  must  decide 
on  what  to  build  in-house,  what  to  subcontract, 
and  when  to  place  procurement  orders.  In 
addition,  the  level  of  the  documentation  to  be 
developed  must  be  determined. 


are  required  for  a  production  program.  A  pilot 
production  effort  is  also  required  in  order  to 
get  the  "bugs"  out  of  the  manufacturing  pro¬ 
cesses.  Make  or  buy  decisions  receive  formal 
attention  and  are  made  at  the  detail  level. 
Finally,  extensive  use  of  material  requirements 
planning  (MRP)  is  used  to  efficiently  manage 
inventories  and  cash  flow. 


The  production  of  a  prototype  or  a  one  of 
a  kind  device  usually  involves  taking  many 
production  short  cuts.  The  documentation  effort 
is  usually  limited  to  engineering  drawings  and, 
in  some  cases,  engineering  sketches.  Manufac¬ 
turing  drawings  are  seldom  required  due  to  the 
fact  that  most  items  are  built  in  the 
engineering  laboratories  or  model  shops.  Formal 
make  or  buy  decisions  are  not  common  place.  The 
contractor  will  generally  build  what  he  can  and 
buy  what  he  cannot  build  himself.  Procured 
items  are  placed  on  order  when  they  are 
identified  and  some  are  ordered  in  anticipation 
of  need. 

A  full  production  program  will  have 
different  objectives  than  a  prototype  program. 
Complete  engineering  and  manufacturing  drawings 


A  limited  production  trainer  program  uses 
the  techniques  from  both  prototype  and  full 
production  programs.  Complete  engineering  and 
limited  manufacturing  drawings  are  developed. 
Manufacturing  drawings  are  only  developed  for 
the  relatively  large  quantity  items.  (On  a 
limited  production  trainer  program,  one  must 
look  to  the  subsystem  and  detail  level  in  order 
to  identify  what  is  applicable  to  full  pro¬ 
duction  techniques.)  Pilot  production  programs 
are  not  conducted  at  the  trainer  system  or  sub¬ 
system  level.  Make  or  buy  decisions  are 
performed  for  major  cost  items  only,  and 
material  requirements  planning  is  also  only  used 
on  major  cost  items.  A  summary  of  the 
production  objectives  for  prototype,  full 
production  and  limited  production  programs  is 
shown  in  Table  3. 


TABLE  3. 


PRODUCTION  OBJECTIVES 


PROTOTYPE  OBJECTIVES 


1.  Limited  engineering 
drawings . 

2.  Build  what  you  can  in  the 
engineering  laboratory  or 
model  shop. 

3.  Few  formal  make  or  buy 
decisions. 

4.  Buy  most  items  when  they 
are  identified  and  some  in 
anticipation  of  need. 


FULL  PRODUCTION  OBJECTIVES 

1.  Complete  engineering  and 
manufacturing  drawings. 

2.  Pilot  production  to  get 
the  '"bugs"  out  of  the 
process . 

3.  Make  or  buy  decisions. 

4.  Extensive  use  of  material 
requirements  planning. 


U_M!_TED  PRODUCTION  OBJECTIVES 

1.  Complete  engineering  and 
limited  manuf ac t ur 1 ng 
drawings . 

2.  No  pilot  production 
program. 

3.  Make  or  buy  decisions  for 
major  cost  items  only. 

4.  Use  of  material  require¬ 
ments  planning  on  major 
cost  items. 


TESTING 

The  testing  process  of  a  trainer  system 
can  perform  a  needed  functional  quality  and 
functional  configuration  checking.  In  addition, 
testing  early  in  the  production  process  can 
identify  problems  at  the  level  where  they  can  be 
efficiently  remedied. 

On  a  prototype  program,  almost  all  the 
testing  is  performed  by  the  design  engineer  or 
programmer.  The  designer  will  normally  start 
his  testing  at  a  higher  level  than  on  a 
production  program  because  he  is  more  intimate 
with  the  design  and  can  quickly  identify  and 
solve  problems.  Formal  test  specifications  are 
not  required  because  the  designer  knows  what  the 
performance  of  the  device  should  be. 

Full  production  testing  programs  are 
entirely  different  from  prototype  testing 
programs.  Formal  test  specifications  and 
manufacturing  test  tools  are  required  because 
people  other  than  the  original  designer  are 
going  to  perform  the  testing.  Testing  is  also 
performed  at  the  bareboard,  board,  subsystem  and 
system  level  in  order  to  Identify  and  remedy 
problems  at  a  level  where  people  other  chan  the 
original  designer  can  perform  this  function. 
Finally,  the  testing  at  the  lower  levels  can 
provide  an  electrical  configuration  audit  to 
verify  that  all  components  of  the  device  are 


functionally  identical,  including  follow-on 
spares  at  a  later  date. 

The  testing  objectives  for  a  limited 
production  trainer  closely  follow  the  full 
production  program  testing  objectives.  Testing 
is  a  means  of  verifying  a  conceptual  design 
and/or  verifying  that  the  assembly  process  was 
performed  correctly  and  that  all  the  components 
are  functional.  During  the  development  phase  of 
a  limited  production  program  in  which  the  first 
training  device  is  produced,  the  testing  process 
is  more  Important  for  verifying  a  conceptual 
design.  Once  the  first  unit  is  working,  the 
testing  process  becomes  more  of  a  check  on  the 
assembly  process,  including  verifying  that  all 
the  components  are  functional.  If  test 
specifications  and  manufacturing  test  tools  are 
developed  during  the  development  phase,  an 
electrical  configuration  audit  can  be  performed 
on  the  final  configuration  of  the  development 
unit  prior  to  starting  the  follow-on  production 
units.  An  electrical  configuration  audit  is  the 
re-testing  of  the  known  working  system  boards 
and  subsystems  on  the  manufacturing  test  tools. 
This  is  done  to  verify  that  the  test 
specifications  and  test  tools  are  to  the  latest 
functional  configuration  prior  to  being  used  for 
a  limited  production  run  (see  Figure  1.)  A 
comparison  of  the  testing  objectives  of 
prototype,  full  production  and  limited 
production  programs  are  presented  in  Table  4. 


FIGURE  1.  ELECTRICAL  CONFIGURATION  AUDIT  ON  FIRST  UNIT 


125 


'V  «  4  *  •  «  1  ,  '  *.*«•' 


TABLE  4. 


TESTING  OBJECTIVES 


PROTOTYPE  OBJECTIVES 

1.  No  test  specifications. 

2.  No  manufacturing  test 
tools. 

3.  Design  engineer  or 
programmer  will  test  out 
all  levels  of  system. 

4.  Most  testing  will  be 
performed  at  system  level. 


FULL  PRODUCTION  OBJECTIVES 

1.  Test  specifications  are 
required. 

2.  Manufacturing  test  tools 
are  required. 

3.  Manufacturing  test 
performs  testing 
functions. 

4.  Testing  is  performed  at 
bareboard,  board,  sub¬ 
system  and  system  levels. 

5.  Board  and  sub-system 
testing  can  be  used  as  an 
electrical  configuration 
audit. 


U M I  TED  PRODUCT  I ON  OBJECT I V ES 

1.  Test  spec i f i cat  ions  are 
required  for  most  items. 

2.  Manufacturing  test  tools 
are  required  for  most 

i terns . 

3.  Manufacturing  test 
performs  the  lower  levels 
of  testing.  Engineering 
performs  the  system 

test ing. 

4.  Board  and  sub-system 
testing  can  be  used  as  an 
electrical  configuration 
aud i t . 


SUPPORT  OBJECTIVES 

Developing  a  good  long  term  support 
program  within  the  commercial  grade  trainer 
budget  and  schedule  is  no  simple  matter.  In 
order  to  meet  the  budget  requirements  of  a 
program,  extensive  use  of  commercial  equipment, 
especially  computers  which  go  out  of  production 
in  three  to  five  years,  is  required.  This 
requires  an  agreement  with  the  Original 
Equipment  Manufacturer  (O.E.M. )  that  they  will 
support  their  equipment  for  the  life  cycle  of 
the  trainer.  Documentation,  training  and 


maintenance  for  limited  production  trainers 
usually  follow  the  requirements  for  a  full 
production  program  with  the  exception  of 
commercial  equipment.  Commercial  grade 
documentation  and  contractor  maintenance  are 
acceptable  alternatives  to  full  military 
documentation  and  support  for  trainers  because 
trainers  are  usually  located  with  the  United 
States  and  within  easy  access  to  most  support 
requirements.  Table  5  shows  a  support  objective 
comparison  of  prototype,  full  production  and 
limited  production  programs. 


TABLE  5.  SUPPORT  OBJECTIVES 


PROTOTYPE  OBJECTIVES 

1.  Minimum  documentation 

2.  Use  developer  for 
maintenance  function. 


FULL  PRODUCTION  OBJECTIVES 

1.  Full  military  documen¬ 
tation. 

2.  User  to  perform 
maintenance  function. 

3.  Training  courses. 

4.  Tull  spares  put  into 
military  supply  system. 


LIMITED  PRODUCTION  OBJECTIVES 

1.  Commercial  or  full 
military  documentation. 

2.  User  or  contractor  to 
perform  maintenance 
function. 

3.  Training  courses. 

4.  Depot  at  developer’s 
factory  and  vendor 
services  for  O.E.M. 
equipment . 


CONCLUSION 

Management  of  a  low  quantity,  high 
technology  trainer  development  program  requires 
that  the  program  management  team  be  familiar 
with  prototype  and  full  production  techniques. 
It  is  only  by  the  careful  selection  and 
application  of  these  techniques  that  a  limited 
production  program  can  be  fully  successful. 
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ABSTRACT 

This  study  was  initiated  to  develop  a  document  to  be  used  for  the  planning  and  pro¬ 
gramming  of  simulation  acquisition  in  support  of  Marine  Corps  training. 

Generic  training  task  requirements  in  the  ground  combat  (C),  combat  support  (CS) 
and  combat  service  support  (CSS)  fields  which  can  be  enhanced  through  the  use  of  simu¬ 
lation  were  identified.  Tradeoff  analyses  were  performed  to  develop  prioritized  lists 
of  the  tasks  for  which  simulators  should  be  developed  and  of  recommended  generic-type 
simulation  devices. 

The  extent  of  the  need  for  simulation  was  assessed  by  determining  which  of  the 
training  task  requirements  would  be  improved  by  the  use  of  simulation,  taking  into  ac¬ 
count  the  technology  state-of-the-art  (SOA).  Measures  of  quality  of  training  used 
included:  performance,  time  to  train,  training  cost,  personnel  support,  technological 
risk,  integratability  with  other  training,  and  special  assets  requirements. 

This  paper  describes  the  methodology  applied  and  the  results  obtained.  Special 
emphasis  is  put  on  the  criteria  utilized  and  the  planned  future  use  of  the  results. 


The  purpose  of  the  study  reported  here  was  to 
develop  a  prioritized  list  of  ground  combat, 
combat  support  and  combat  service  support  tasks 
for  which  simulation  would  economically  improve 
training.  This  prioritization  is  critical  because 
the  number  of  tasks  whose  effective  training  can 
be  supported  through  simulation  cannot  be  fully 
supported  by  available  resources.  The  study  re¬ 
sulted  in  a  baseline  of  tasks  and  simulation 
technology  for  Marine  Corps  efforts  to  define  and 
incorporate  simulator  training  during  the  1985- 
1995  timeframe. 

To  fulfill  such  a  purpose,  the  objectives  of 
the  study  were  to: 

•  Determine  those  training  requirements  in  the 
ground  combat  (C),  combat  support  (CS),  and 
combat  service  support  (CSS)  fields  which 
could  be  enhanced  through  the  use  of  simula¬ 
tion,  and 

•  Develop  a  prioritized  listing  of  recommended 
generic-type  simulation  devices,  based  on 
current  and  emerging  technology,  which  would 
be  capable  of  satisfying  those  requirements. 

For  purposes  of  meeting  the  objectives  of  the 
study,  a  simulator  was  defined  as  a  device  which 
provides  a  functional  replication  of  hardware  or 
operational  system  In  an  environmental  context  and 
which  requires  Interaction  between  it  and  the 
trainee(s) . 


APPROACH 

The  approach  started  with  a  review  of  extant 
system  front-end  analyses  results,  followed  by  the 
determination  of  tasks  to  be  trained,  the  develop¬ 
ment  of  training  objectives,  the  determination  and 
evaluation  of  training  approach  alternatives,  the 
tentative  selection  of  device  needs,  and  a  cost/ 
benefit  analysis.  This  study  contains  the  basic 
elements  of  this  approach  at  a  depth  of  detail 
consistent  with  the  broad  scope  of  interest  en¬ 
tailed  when  addressing  all  the  tasks  which  are 
encompassed  by  the  C,  CS  and  CSS  fields. 

In  deciding  on  the  depth  of  detail  that  would 
be  consistent  with  the  study's  purpose,  considera¬ 
tion  was  given  to  the  stated  need  to  provide  a 
structure  within  which  programmers  could  identify 
where  funds  for  simulation  would  provide  the  best 
returns.  In  this  context  two  parameters  were  of 
most  concern.  The  first  dealt  with  the  ability  to 
identify  validated  training  requirements.  Per¬ 
formance  of  detailed  task  analyses  for  each 
military  occupational  specialty  (MOS)  in  each  of 
the  three  fields  of  interest  would  have  resulted 
in  a  study  of  much  longer  duration  and  thus  be 
inconsistent  with  the  immediate  need.  The  solu¬ 
tion  was  to  utilize  existing  documentation, 
supplemented  by  discussions  with  Marine  Corps' 
personnel  responsible  for  training.  When  combined 
with  the  methodology  developed  as  part  of  the 
study,  this  would  provide  action  officers  with  a 
valuable  tool  that  would  mature  as  further  analy¬ 
ses  were  conducted. 


The  second  concern  dealt  with  the  level  of 
definition  of  simulation  concepts.  It  was  felt 
that  creation  of  a  catalog  of  devices  would  be 
time  consuming,  would  produce  an  unmanageable 
document  and  wouldn’t  be  what  was  really  needed. 
Taking  the  above  concerns  and  others  into  con¬ 
sideration,  the  approach  to  the  study  was  defined 
by  bounding  the  scope  with  the  following  guide¬ 
lines: 

•  Definition  of  training  requirements  was  based 
on  a  comprehensive  review  of  the  combat, 
combat  support,  and  combat  service  support 
fields  (including  maintenance  requirements). 

•  Training  requirements  were  defined  in  generic 
terms  as  opposed  to  specific  hardware. 

A  cordingly,  concepts  were  defined  in  terms 
of  generic  types  of  simulation,  as  opposed  to 
specific  training  devices. 

•  Training  requirements  described  tasks  to  be 
performed. 

•  A  detailed  task  analysis  of  each  HOS  to 
determine  task  training  requirements  was 
beyond  the  scope  of  the  study.  The  require¬ 
ments  data  base  was  compiled  from  existing 
documentation  and  discussions  with  Marine 
Corps  personnel  responsible  for  training. 

•  Life  cycle  cost  (LCC)  evaluation  was  con¬ 
ducted  based  on  order-of-magnitude  informa¬ 
tion,  since  generic  equipment  is  Involved. 
Major  factors  affecting  LCC  were  Identified. 

•  The  study  took  into  account  increasing  costs 
of  fuel  and  ammunition,  decreasing  availa¬ 
bility  of  ranges  and  training  areas,  environ¬ 
mental  Impacts  on  training,  and  expected 
levels  of  learning  for  future  user  popula¬ 
tions. 

The  general  approach  used  in  performing  the 
study  consisted  of  four  parts:  (1)  development  of 
the  study  framework,  (2)  assessment  of  the  need 
for  simulation,  (3)  prioritization  of  the  simula¬ 
tion  alternatives,  and  (4)  development  of  a  base¬ 
line  for  future  efforts  to  define  and  incorporate 
simulator  training  irf  the  Marine  Corps. 


STUDY  FRAMEWORK 

The  framework  within  which  the  study  was  to 
be  performed  was  established  by  the  conduct  of  a 
comprehensive  review  of  Marine  Corps  needs  in 
order  to  define  current  and  projected  training 
requirements  and  to  develop  a  training  require¬ 
ments  data  base.  Also,  the  state-of-the-art  (SOA) 
In  simulation  technology  was  determined  and  a 
technology  data  base  was  developed. 


The  output  of  the  review  cf  training  require¬ 
ments  was  a  generalized  task  list.  This  list  was 
basic  to  the  study  in  that  it  represented  the 
scope  of  training  requirements  for  which  the 
applications  of  simulation  were  to  be  evaluated. 

Both  equipment-oriented  and  mission-oriented  tasks 
were  considered. 

The  product  of  the  technology  survey  task 
consisted  of  a  summary  of  the  technology  base  that 
will  be  available  in  the  1985-1995  period  which 
could  meet  the  requirements  of  Marine  Corps 
training.  The  survey  encompassed  simulation 
technology  currency  available,  in  the  development 
stage  and  proposed.  Emerging  technology  was 
identified. 

TASK  1  -  Review  of  General  Training  Requirements 

The  success  of  the  data  collection  and  review 
effort,  it  was  recognized,  would  be  dependent  on 
acquiring,  early,  a  clear  understanding  of  the 
Marine  Corps^'l  training  philosophy,  training  sys¬ 
tem,  and  internal  responsibilities  at  all  echelons 
involved  in  training.  From  this  training  frame¬ 
work,  the  data  sources  (documentary ,  institu¬ 
tional,  and  field  unit)  could  be  identified  and 
the  data  collection  effort  structured.  Accordingly, 
following  an  initial  coordination  meeting  with  the 
Contract  Officer's  Technical  Representative  (COTR) 
and  selected  Marine  Corps  representatives,  the 
Falcon/XMCO  team  visited  the  Marine  Corps  Develop¬ 
ment  and  Education  Command  (MCDEC)  and  Headquar¬ 
ters,  U.S.  Marine  Corps  ( HQMC ) .  The  primary 
thrust  of  these  meetings  was  to  explore  the 
training  situation  within  the  Marine  Corps.  The 
visits  proved  to  be  especially  valuable  in  view  of 
the  on-going  initiatives  to  restructure  the 
training  system.  The  information  gained,  through 
briefings  and  documentation,  covered  the  in-house 
studies  which  resulted  in  the  changes  which  are 
occurring,  the  organizational  and  responsibility 
realignments  made,  the  procedural  changes  being 
instituted  which  affect  the  methods  used  in 
training  development,  and  a  perspective  of  the 
direction  and  objectives  of  the  training  system. 

With  regard  to  this  task,  the  information  of 
overall  Interest  (both  current  and  projected) 
included:  the  composition  of  the  C,  CS,  and  CSS 
fields;  their  associated  weapons/hardware  systems; 
task  analysis  or  other  data  reflecting  general 
training  requirements;  critical  tasks;  training 
deficiencies  and  problem  areas;  and  the  impact  of 
NBC  defense  requirements  on  training.  The  sources 
used  to  acquire  this  information  Included:  HQMC, 
MCDEC,  and  field  visits  to  agencies  and  units  at 
Camp  Lejeune,  North  Carolina;  Camp  Pendleton, 
California;  Marine  Corps  Air  Ground  Combat  Center, 
Twenty-Nine  Palms;  the  Landing  Force  Training 
Center,  Norfolk;  and  the  Naval  Training  Equipment 
Center  (NTEC),  Orlando,  Florida. 


Task  training  requirements  were  grouped  into 
two  general  categories:  those  associated  with  the 
operation  and  maintenance  of  equipment  (i.e., 
tanks,  trucks,  radios,  etc.),  and  those  which 
derive  from  the  mission  requirements  of  a  C,  CS, 
or  CSS  unit  (i.e.,  operational  functions).  The 
former  are  primarily  individual  tasks  whereas  the 
latter  are  primarily  collective  tasks. 

The  source  data  for  the  MOS/equipment-oriented 
tasks  consisted  of  the  Marine  Corps'  Military 
Occupational  Specialties  Manual  (MCO  P12000.7D 
with  Changes  1,  2,  and  4),  a  machine  printout  of 
tasks  extracted  from  U.S.  Army  Soldier's  Manuals 
and  extracts  of  Computerized  Occupational  Data 
(CODAP)  for  selected  MOSs,  obtained  from  Head¬ 
quarters,  Marine  Corps.  The  Marine  Corps'  Combat 
Readiness  Evaluation  System  (MCCRES)  volumes  were 
the  main  source  for  mission-oriented  task  data. 
Also,  personnel  directly  responsible  and  involved 
in  training  provided  inputs  in  developing  the 
mission-oriented  task  list. 

The  overall  task  list  contained  198  mission- 
oriented  tasks  and  1564  MOS/equipment-oriented 
tasks  contained  in  123  MOSs  for  22  occupational 
fields  (OP).  The  combat,  combat  support,  and 
combat  service  support  occupational  fields  of 
interest  are  listed  in  Table  1.  Table  2  presents 
the  first  ten  (out  of  24)  tasks  of  the  0311  Rifle¬ 
man  MOS  as  an  example  of  the  type  of  MOS -oriented 
tasks  contained  in  the  list.  These  tasks  will  be 


Table  2 

Sample  MOS-Oriented  Tasks 

OF  03  Infantry 

MOS  0311  Rifleman 

1.  Cleans  and  maintains  service  rifle,  grenade 
launcher,  and  intracompany  communications 
equipment. 

2.  Engages  targets  with  the  service  rifle, 
grenade  launcher,  light  antitank  weapons, 
hand  grenades,  and  command  detonated  anti¬ 
personnel  mines. 

3.  Controls/performs  fire  team,  squad  and 
platoon  movements. 

4.  Camouflages  and  conceals  self  and  indi¬ 
vidual  equipment. 

5.  Navigates  using  a  map  and  compass. 

6.  Applies  first-aid. 

7.  Transmits  and  receives  messages  using 
intracompany  communications  equipment. 

8.  Reports  information  on  the  enemy,  using 
"salute"  report. 

9.  Handles  prisoners  of  war. 

10.  Executes  embarkation  and  debarkation  from 
helicopters  and  amphibious  ships. 


Table  1 

Combat,  Combat  Support  and  Combat  Service  Support 
Occupational  Fields 


Personnel  and  Administration 

Intel ligence 

Infantry 

Logistics 

Field  Artillery 

Utilities 

Engineer,  Construction,  Equipment,  and 
Shore  Party 

Drafting,  Surveying,  and  Mapping 
Tank  and  Amphibian  Tractor 
Ordnance 

Ammunition  and  Explosives  Ordnance 
Disposal 

Operational  Communications 

Signals  Intelligence/Ground  Electronic 

Warfare 

Data/Cormunications  Maintenance 
Supply  Administration  and  Operations 
Transportation 
Food  Service 

Auditing,  Finance,  and  Accounting 
Motor  Transport 
Data  Systems 

Nuclear,  Biological,  Chemical 

Military  Police 

Officers 


utilized  later  in  the  paper  to  demonstrate  the 
methodology  that  was  followed  in  defining  tasks 
whose  training  would  be  enhanced  by  simulation. 
Table  3  presents  a  sample  set  of  mission-oriented 
tasks  for  the  amphibious  raid  mission. 


Table  3 

Sample  Mission-Oriented  Tasks 


15.  Amphibious  Raid 

a. 

Conduct  Planning 

b. 

Performs  Preparations 

c. 

Develop  a  Concept  of  Operations 

d. 

Task  Organize 

e. 

Develop  a  Scheme  of  Maneuver 

f. 

Conduct  Ship  to  Shore  Movement 

9- 

Move  to  Raid  Objective 

h. 

Assault  the  Raid  Objective 

1. 

Retire  to  the  Extraction  Point 

j. 

Conduct  Reembarkation 

k. 

Conduct  Debriefing 
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TASK  2  -  Technology  Survey 

The  technology  data  base  survey  encompassed 
simulation  technology  currently  In  existence,  in 
the  development  stage  and  proposed.  Emerging 
simulator  technology  that  may  be  responsive  to 
specific  mission  area/weapon  system  general 
training  requirements  was  identified. 

As  a  result  of  discussions  with  personnel 
cognizant  of  the  USMC  training  programs/facilities 
at  both  the  support  and  operating  force  levels,  a 
USMC  training  device/simulation  source  data  base 
of  current  and  desired  items  was  developed. 
Information  on  developmental  items  together  with 
emerging  technology  within  the  simulation  field 
was  added  through  contact  with  NTEC  personnel /USMC 
Liaison  Officers  and  PM  TRADE  representatives. 

Since  training  devices/simulators  are  not 
service  peculiar,  a  survey  of  U.S.  Army  training 
devices/simulators  for  those  items  of  equipment, 
systems  and  functions  common  to  both  USMC  and  Army 
training  requirements  was  made.  Much  of  this 
information  was  supplied  by  the  U.S.  Army  Training 
Support  Center  at  Ft.  Eustis,  Virginia.  Informa¬ 
tion  on  foreign  and  other  existing  technology  was 
also  gathered  through  a  survey  of  published 
material  and  discussions  with  a  number  of  industry 
representatives. 

Although  many  of  the  technological  areas  are 
unique,  most  are  used  in  support  of  one  another  to 
achieve  a  desired  simulation  effect.  Therefore, 
they  can  be  consolidated  into  the  following  disci¬ 
plines  of  simulation  technology  that  are  at  the 
forefront  of  the  indicated  emerging  trends: 

A  Data  Processing 

Reduced  Componentry/Environmental 
Requirements 

High  Speed  Micro-Micro  Electronics 

Transferabllity/Flexibility  of  Software/ 
Courseware  Modules 

a  Visual  Simulation 

HI-Resolutlon/HI-Density  Realtime  Video/ 
Digital  Discs/Computer  Generated 
Imagery  (CGI) 

a  Engagement  Simulation 

Eye-Safe  Lasers/Area  Lasers 

Imbedded  Sensors 

"Safe"  Ammunition 

Holographic/Liquid  Crystal  "Terrain" 
Displays 

Robotics 

Games 


Thermal  Signature  Generators 
Gas  Producers 

a  Equipment  Simulation 
Operable  Mockups 
Part-Task  Trainers 

a  Surrogate  Learning 

Automatic  User-oriented  Software/ 

Courseware  with  Voice  Synthesis 

Video  Games 

Embedded  Training  Systems 
Measures  of  Effectiveness 

Development  of  this  technology  could  have  any  of 
the  following  effects  on  training  effectiveness: 

a  Real-time/better  resolution 

a  Increased  functionality  (more  power  for  the 
same  size  or  same  power  for  a  smaller  size)/ 
shipboard  applicability 

A  Increased  direct  fire  ranging  (safe  focusing) 
allowing  force-on-force  with  combined  arms 
operations 

a  More  detailed  visuals  with  greater  fidelity 

A  Reduced  componentry/storage  requirements  for 
visual  resolution/fidelity 

a  3-D  visual  displays 

a  Low  cost  simple  displays  (speed  not  critical) 

a  Allowance  for  "missing  person"  response  in 
war  games 

a  Realistic  gunnery  training  target/identifi¬ 
cation  using  night  vision  devices 

a  Reduced  range/environmental  constraints 

A  Improved  weapon  environmental  effects 
(obscuration) 

a  Added  incentive  to  train  with  low  cost 

a  Situation  scoring  response  (realism) 

a  Allows  indirect  fire  applications  in  force- 
on-force  operations 

a  Increased  realism  to  built-up  area  operations 

Using  the  results  of  the  technology  survey, 
generic  technology  categories  were  established  and 
are  presented  in  Table  4.  Candidates  for  simula¬ 
tion  training  of  the  tasks  previously  identified 
were  chosen  from  this  list. 
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Generic  Technology  Categories 


CODE 

GENERIC  TECHNOLOGY 

EXAMPLE 

EMM 

El ec tromechani cal /microprocessor 

Panel  board  trainer 

VDM 

Video-di sc/microprocessor 

Video-disc  COFT  -  firing  trainer 

CGI 

Computer-generated  imagery/computer 

Ml  tank  gunnery  trainer 

TG 

Tactical  game  (manual  or  computerized) 

TACWAR,  TWSEAS  -  war  gaming  trainers 

OM 

Operable  mockup 

Satellite  communications  repair  trainer 

SED 

Signal  emi tter/detector 

Radiac  training  device 

I  DM 

Interactive  display/microprocessor 

Noncomnunication  intercept/EW  trainer 

IR 

Infrared  transmitter/detector 

REDEYE  trainer 

L 

Laser  transmitter/detector 

MILES  -  laser  qun  fire  trainer 

TB 

Terrain  board 

Amphibious  assault  trainer 

BS 

Ballistic  simulation 

Pneumatic  mortar  trainer 

MO 

Mechanical -optical /microprocessor 

Observed  fire  trainer 

NAT 

No  applicable  technology  identified 

NEEDS  ASSESSMENT 


TASK  3  -  Quality  of  Training  Assessment 


Once  the  framework  for  the  study  was  estab¬ 
lished,  the  extent  of  the  need  for  simulation  was 
assessed  by  determining  which  of  the  training  re¬ 
quirements  would  be  improved  by  use  of  simulation, 
taking  into  account  the  technology  SOA.  For  those 
requirements,  an  evaluative  data  base  was  developed. 

The  output  of  the  first  task  in  the  needs 
assessment  phase  of  the  study  (quality-of- training 
assessment)  was  a  requirements/concepts  matrix 
which  was  developed  by:  (1)  matching  simulation 
alternatives  with  training  requirements,  (2)  apply¬ 
ing  the  quality-of-training  criteria  and  (3)  identi¬ 
fying  those  requirements  that  would  be  improved  by 
the  use  of  simulators.  The  measures  of  quality- 
of-training  employed  four  criteria: 

•  Higher  performance 

•  Decreased  time  to  train 

•  Decreased  training  cost 

•  Decreased  personnel  support  costs 

In  the  second  task  during  this  phase  of  the 
study  (evaluation  of  requirements/concepts)  fur¬ 
ther  evaluation  of  the  requirements/corcepts 
matrix  was  performed  to  establish  a  data  base  for 
the  prioritization  of  the  concepts.  Criteria  that 
were  applied  included: 

•  Cost  and  risk  factors 

•  Integratability  with  other  training 

•  Special  assets  requirements 


An  overview  of  the  methodology  used  in  the 
performance  of  this  task  is  shown  in  Figure  1. 
Essentially,  the  methodology  represents  a  series 
of  "gates"  through  which  each  task  must  pass 
successfully  in  order  to  remain  a  candidate  for 
the  Marine  Corps  program  to  enhance  training 
through  the  use  of  simulation. 

The  first  gate  in  the  process  applied  five 
(5)  criteria  to  the  generalized  task  list  in  order 
to  identify  those  tasks  that  need  to  be  or  could 
be  improved  and  thus  should  be  given  priority  and 
emphasis  in  the  simulation  analysis.  Those  tasks 
which  met  one  or  more  of  the  criterion  were  re¬ 
tained  for  further  analysis.  The  criteria  re¬ 
tained  tasks  which:  (1)  presently  require  facili¬ 
ties/resources  limited  in  availability  or  expend¬ 
able,  (2)  were  identified  as  experiencing  training 
problems  or  inability  to  train,  (3)  have  demonstra¬ 
ted  weaknesses  or  shortfalls  in  unit  performance, 
(4)  are  mission-critical,  and/or  (5)  are  mobiliza¬ 
tion/reserve  forces  oriented. 

Application  of  criteria  (1)  and  (2)  was  based 
on  survey/interview  data  gathered  during  visits  to 
Marine  Corps  facilities.  Criterion  (3)  was  based 
on  Marine  Corps  Combat  Readiness  Evaluation  Sys¬ 
tems  (MCCRESS)  reports  and  the  tactical  exercise 
evaluations  at  29  Palms.  Criteria  (4)  and  (5) 
were  based  on  analysis  of  task  requirements  by  the 
study  team.  Out  of  the  original  1762  tasks,  394 
were  deleted  through  this  step. 
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TASK  3 


Figure  1 

Task  3  Methodology  Overview 


The  second  gate  applied  the  first  of  four 
criteria  used  to  identify  those  training  tasks 
that  would  be  improved  by  the  use  of  simulation. 
This  "higher  performance"  criterion  was  applied 
using  a  methodology  which  did  not  require  identi¬ 
fying  the  specific  simulation  technologies  appli¬ 
cable  to  each  task.  The  methodology  employs,  as  a 
guide,  the  procedures  defined  in  the  Instructional 
Systems  Development  (ISD)*-2^  model  for  selecting 
the  training  delivery  approach  which  best  permits 
the  application  of  learning  guidelines  established 
by  the  model.  In  this  process,  training  tasks  are 
addressed  in  terms  of  their  behavioral  attributes 
(mental,  physical  and.attitudinal)  essential  for 
task  performance.  The  ISD  model  associates  the 
behavioral  attributes  for  a  task  with  a  learning 
subcategory  and  provides  learning  guidelines  to  be 
used  in  developing  effective  training.  For  each 
learning  subcategory,  ISD  also  identifies  the 
alternative  delivery  approaches  (e.g.,  simulator, 
operational  equipment,  computer  aided  instruction, 
etc.)  which  will/will  not  permit  complete  applica¬ 
tion  of  the  learning  guidelines,  considering  task 
stimulus  criteria. 

In  applying  the  above  methodology,  the  follow¬ 
ing  procedure  was  employed.  If  the  task  met  one 
or  more  of  the  first  three  of  the  five  criteria 


applied  at  the  first  gate,  it  was  concluded  that 
simulation  would  result  in  higher  performance  and 
the  task  was  retained  for  further  evaluation.  If 
the  task  had  been  retained  after  having  met  only 
the  fourth  or  fifth  criterion,  the  methodology  was 
applied.  The  results  of  a  behavioral-attributes 
analysis,  along  with  application  of  the  guidance 
which  relates  the  associated  learning  subcate¬ 
gories  with  alternative  delivery  approaches 
(e.g.,  simulator,  operational  equipment,  etc.), 
were  used  to  predict  higher  performance.  Those 
tasks  for  which  the  prediction  of  higher  per¬ 
formance  through  the  use  of  simulation  was  nega¬ 
tive  were  deleted  from  further  analysis;  452  tasks 
were  deleted,  leaving  916  out  of  the  original  1762 
tasks. 

For  each  training  task  identified  in  which 
the  use  of  simulation  would  improve  the  quality  of 
training,  a  determination  was  made  as  to  what  type 
of  generic  technology  categories  (as  defined  in 
Task  2  and  listed  in  Table  4)  would  be  applicable 
to  produce  an  envisioned  benefit  in  training 
quality.  An  applicable  simulation  technology 
could  not  be  identified  for  174  tasks.  These  were 
removed  from  further  consideration,  but  a  list  of 
these  tasks  was  Included  in  the  report  for  peri¬ 
odic  review. 
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The  three  remaining  qual  i  ty-of-trai  ni  ng  cri¬ 
teria  addressed  whether  the  use  of  simulation 
will,  for  the  same  level  of  proficiency,  decrease: 
(1)  training  time,  (2)  training  costs,  and 
(3)  support  personnel  costs.  They  were  applied  to 
the  training  task/technology  matrix.  Those  tasks 
for  which  at  least  one  of  the  three  criteria  would 
be  improved  by  simulation  were  retained  (84  out  of 
742  were  dropped  from  further  consideration  at 
this  gate) . 

Performance  of  the  quality  of  training  evalua¬ 
tion  resulted  in  the  assessment  that  658  (505  MOS/ 
equipment-oriented  and  153  mission-oriented)  tasks 
out  of  the  original  list  of  1762  would  be  enhanced 
by  the  use  of  simulation.  The  data  developed  for 
this  part  of  the  effort,  including  the  simulation 


alternatives  identified  with  each  task,  provide  an 
audit  trail  for  arriving  at  the  list  of  tasks. 

Table  5  summarizes  the  results  of  the  quality- 
of-training  assessment  for  the  ten  tasks  of  the 
Rifleman  MOS  (Table  2)  being  used  to  demonstrate 
the  methodology.  From  the  results  we  see  that  one 
(No.  6)  did  not  make  it  through  the  initial 
screening  (five  criteria).  Two  more  (Nos.  1 
and  9)  did  not  pass  through  the  higher  performance 
(P)  criterion.  When  the  generic  technology  cate¬ 
gories  were  matched  with  the  remaining  tasks,  no 
concepts  were  found  which  could  satisfy  the  re¬ 
quirements  for  two  of  them  (Nos.  5  and  8).  These 
two  tasks  were  removed  from  further  consideration 
in  the  study,  but  were  compiled  into  a  separate 
list  for  future  review.  Of  the  remaining  five 


Table  5 

Qual i ty-of-Training  Summary  Data 


OF:  03  -  INFANTRY 

INITIAL 

SCREENING 

QUALITY  OF 
TRAINING  SCREENING 

SIMULATION 

TECHNOLOGY 

0311  RIFLEMAN 

FR 

PB 

PF 

MC 

MB 

P 

T 

TC 

SC 

ALTERNATIVES** 

1.  Cleans  and  Maintains  Service  Rifle, 
Grenade  Launcher,  and  Intra-Company 
Communications  Equipment 

N 

N 

N 

Y 

Y 

N 

2.  Engages  Targets  With  the  Service  Rifle, 
Grenade  Launcher,  Light  Antitank 

Weapons,  Hand  Grenades,  and  Command 
Detonated  Antipersonnel  Mines 

Y 

Y 

N 

Y 

Y 

Y 

Y 

Y 

YNN* 

VDM 

IR/L 

L 

3.  Controls/Performs  Fire  Team,  Squad 
and  Platoon  Movements 

Y 

N 

Y 

Y 

Y 

Y 

Y 

YN 

YN 

TB 

L 

4.  Camouflages  and  Conceals  Self  and 
Individual  Equipment 

Y 

Y 

N 

Y 

Y 

Y 

N 

N 

N 

L 

5.  Navigates  Using  a  Map  and  Compass 

Y 

Y 

N 

Y 

Y 

Y 

- 

- 

NAT 

6.  Applies  First-Aid 

N 

N 

N 

N 

N 

- 

- 

- 

- 

7.  Transmits  and  Receives  Messages  Using 
Intra-Company  Communications  Equipment 

N 

Y 

Y 

Y 

Y 

Y 

N 

Y 

N 

OM 

8.  Reports  Information  on  the  Enemy, 

Using  "Salute"  Report 

Y 

N 

N 

Y 

Y 

Y 

_ 

_ 

NAT 

9.  Handles  Prisoners  of  War 

N 

N 

N 

Y 

N 

N 

- 

- 

- 

- 

10.  Executes  Embarkation  and  Debarkation 

From  Helicopters  and  Amphibious  Ships 

Y 

Y 

N 

Y 

Y 

Y 

Y 

Y 

Y 

_ 

OM 

KEY:  FR  -  Facilities  or  Resources  Required  to 
Conduct  Training 

PB  -  Training  Problem  Identified  During  Field 
Data  Collection  Effort 

PF  -  Performance  Deficiency  Identified  During 
Field  Data  Collection  Effort 
MC  -  Mission  Critical  Task 
MB  -  Mobilization  Training  Task  (IRR) 


P  -  Simulation  Will  Result  in  Improved  Task 
Performance 

T  -  Simulation  Will  Decrease  Training  Time  Required 

TC  -  Simulation  Will  Decrease  Training  Cost 

SC  -  Simulation  Will  Decrease  Support  Personnel 
Requirement  Cost 

N  -  No 

Y  -  Yes 


Where  Multiple  Entries  Occur,  they  Refer  to  the  Technologies  Alternatives  in  the  Order  Listed. 
See  Table  4  for  Definitions. 


tasks,  one  more  (No.  4)  did  not  pass  any  of  the 
remaining  qual i ty-of-training  criteria  and  was 
dropped  from  further  consideration.  Tasks  2,  3, 

7,  and  10  remained  from  this  sample  group. 

TASK  4  -  Evaluation  of  Requirements/Concepts 

For  the  surviving  combinations  of  training 
task/concepts,  the  basis  for  the  prioritization  of 
alternatives  was  established  by  evaluation  in 
terms  of:  (1)  cost/risk  involved  in  using  the 
simulation,  (2)  i ntegratabi 1 i ty  of  the  simulation 
with  other  training  and  (3)  special  requirements 
imposed  by  the  use  of  simulation,  such  as  host 
structure(s) ,  ancillary  equipment,  range  facili¬ 
ties,  etc. 

Essentially,  the  methodology  consisted  of  the 
assessment  of  the  candidate  task/concepts  combina¬ 
tions  in  terms  of  the  evaluative  criteria  using 
data  available  on  current  devices  and  estimates 
for  developmental  and  proposed  systems.  In  this 
context,  the  list  of  current,  developing  and  pro¬ 
posed  simulators/training  devices  was  evaluated  to 
determine  which  ones  could  be  applied  to  a  speci¬ 
fic  MOS  or  mission  training  task  requirements. 

The  resulting  matrix  of  task  requirements  and 
specific  simulation  devices  was  used  in  developing 
qualitative  estimates  for  the  evaluative  criteria. 


CONCEPTS  PRIORITIZATION  (TASK  5) 

Using  the  matrix  of  training  requirements  and 
appropriate  training  concepts  in  conjunction  with 
the  evaluative  criteria  and  results  of  the  require¬ 
ments/concepts  evaluation,  tradeoff  analyses  were 


performed  to  develop  a  prioritized  list  of  recom¬ 
mended  generic-type  simulators.  This  resulted  in 
an  integration  ana  analysis  of  the  data  developed 
in  the  previous  tasks  into: 

•  A  prioritized  list  of  generalized  task  trainin 
requirements,  to  include  a  priori tizaticn  of 
the  generic  technology  approaches  applicable 
to  each  requirement,  and 

•  An  overall  prioritized  list  of  generic  simu¬ 
lation  technology  approaches. 

Taken  collectively,  these  results  provide  the 
Marine  Corps  with  a  baseline  for  training  simula¬ 
tion  development  along  either  of  two  paths.  One 
is  on  the  basis  of  task  training  requirements 
which  should  be  giver  emphasis  in  utilizing  simu¬ 
lation;  the  other  is  on  the  basis  of  the  applicable 
scope  of  generic  simulation  approaches. 

The  generalized  task  requirements  and  associ¬ 
ated  simulation  technologies  considered  in  the 
prioritization  process  were  those  for  which  it  had 
been  determined,  in  Task  3,  that  the  use  of  simu¬ 
lation  would  improve  the  quality  of  training.  A 
flow  diagram  of  the  steps  taken  in  completing  this 
task  is  shown  in  Figure  2. 

The  first  step  in  the  process  was  to  con¬ 
solidate  tasks,  where  appropriate,  on  the  basis  of 
training  commonality.  Through  this  effort,  those 
task  requirements  which  are  common  across  an 
occupational  field(s)  (e.g.,  communicate  using 
rQ'"  'Equipment  or  conduct  planning)  and  those 
whiu..,  in  fact,  are  elements  of  a  larger  task 
(e.g.,  establish  and  operate  an  intelligence 
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Task  5  Methodology  Overview 


section  or  a  fire  support  coordination  center) 
were  combined. 

The  prioritization  process  required  that  10 
criteria  be  applied.  A  rank-ordered  listing  of 
the  criteria  and  the  basis  used  for  rating  them 


are  sumnarized  in  Table  6.  From  a  review  of  the 
criteria,  it  can  be  seen  that  they  fall  into  two 
groups:  those  which  affect  the  prioritization  of 
generalized  task  training  requirements  (items  1,  2, 
and  3)  and  those  which  affect  the  prioritization 
of  applicable  generic  technology  concepts  (items  2, 


Table  6 


Prioritization  Criteria  Rating 


CRITERION 


DESCRIPTION 


1.  Mission  criticality  of  task  trained  For  combat  MOSs/units,  those  tasks  essential  to 

(emphasis  placed  on  combat-type  tasks  accomplishment  of  the  combat  mission;  for  noncombat 
in  anticipated  combat  environment).  MOSs/units,  those  tasks  essential  to  support  combat 

operations  on  a  sustained  basis. 


2.  The  existence  of  training  problems 
or  deficiencies  (due  to  cost  of 
ammunition  and  fuel,  range  availa¬ 
bility  or  other  resource  constraints). 


Information  collected  during  data  col  lection/research 
effort.  Type  of  resources  required  to  conduct 
training  further  divided  into  three  categories  (live 
fire  ranges,  resources  such  as  helicopters,  field 
environment) . 


3.  Commonality  of  type  skills  trained 
(type  of  tasks  using  a  generic 
type  simulator) . 


Combining  of  tasks  based  on  training  commonality; 
potential  training  population  density  for  the  task; 
frequency  of  generic  technology  usage  identified 
with  individual  tasks. 


4.  Site  adaptabi 1 i ty  (ship-  and/or 
shore-based  training). 


5.  Projected  or  estimated  training 
effectiveness. 


6.  Suitability  for  mobilization  and 
reserve  training. 


Simulator  concept,  based  on  generic  technology 
alternatives,  with  regard  to  size,  resources  required 
(e.g.,  environmental  controls),  and  compatibility  with 
amphibious  shipping  used  by  the  Marine  Corps. 

Experience  with  application  of  the  generic  technology 
in  training  the  same  or  similar  tasks;  the  portion  of 
the  task  which  can  be  trained  (full  or  part);  an 
assessment  of  the  technology's  ability  to  simulate 
the  essential  elements  of  a  task. 

For  mobilization,  the  ability  to  reduce  training  time 
(i.e.,  train  large  numbers  of  people  quickly)  and  task 
importance  in  mobilization  training;  for  reserve  use, 
the  probable  availability  of  facilities/area  require¬ 
ments  associated  with  use  of  the  generic  technology. 


7.  Schedule  (i.e.,  projected 
technology  availability) . 


Status  of  current,  developmental,  or  proposed  use  of 
the  technology  to  train  the  same  or  similar  type  tasks. 


8.  Ability  to  modify  the  simulator  to 
reflect  changes  in  training  require¬ 
ments  or  the  hardware/ system  being 
simulated. 


For  training  changes,  the  ability  of  the  user  to  modify/ 
tailor  the  trainer  to  training  needs;  for  hardware/ 
system  changes,  whether  modifications  would  likely 
involve  simple  hardware  changes  or  complex  hardware  a  d/ 
or  software  changes. 


9.  Relative  cost  of  the  simulator/ 
facility. 


Unit  cost  of  similar  existing  devices,  when  possible; 
an  assessment  of  the  task  elements  and  the  complexity 
of  simulation  requirements;  fo  laser  engagement 
simulation,  the  cost  of  a  "battalion  set";  for  games, 
the  size  of  the  group  to  be  trained  using  manual  or 
computerized  versions. 


of  the  technology). 


Current,  developmental,  or  proposed  use  of  the 
technolog.,  , -plication  to  the  same  or  similar  tasks. 


and  4  through  10)  with  regard  to  each  requirement. 
The  criteria  were  applied  accordingly. 

To  facilitate  the  process  of  integrating  and 
applying  the  criteria  and  to  ensure  consistency,  a 
computer  program  was  developed  to  perform  the 
prioritization  function  (Program  for  the  Evalua¬ 
tion  of  Training  Simulation,  PETS).  The  program 
applies  weights  to  each  criterion  and  to  the 
ratings  given  within  each  criterion  to  each  task 
training  requirement  and  the  technology  alterna¬ 
tives.  It  should  be  noted  that  the  application  of 
the  technology  is,  for  the  most  part,  task  de¬ 
pendent.  Therefore,  the  values  assigned  for  a 
particular  technology  may  vary  depending  on  the 
task  requirement.  Figure  3  presents  the  flow 
diagram  for  the  prioritization  methodology. 

A  modified  Delphi  technique  was  used  to 
determine  the  weight  to  be  given  to  each  criterion 
and  the  possible  values  to  be  given  within  each 
criterion.  Seven  retired  officers  (one  brigadier 
general,  two  colonels,  three  lieutenant-colonels, 
and  one  captain)  comprised  the  Delphi  panel.  In 
arriving  at  the  criteria  weightings,  two  con¬ 
straints  were  placed  on  the  group:  that  the  first 
criterion  (mission  criticality)  would  be  rated 
100,  and  that  the  weightings  assigned  to  each 
criterion  could  not  result  in  a  reordering  of  the 
criteria. 


Using  the  data  previously  collected  aid  ttt 
established  ratirg  values,  a  data  sheet  was  pre¬ 
pared  for  each  combined  task,  the  data  was  entered 
into  the  computer,  and  the  program  was  rur . 

Note  the  shaded  area  in  the  flew  diagram. 
Although  not  part  of  the  study  requirement,  the 
training  devices  currently  in  being,  under  develop¬ 
ment,  or  proposed  have  been  identified  with  the 
task  requirements  for  which  they  have  potential 
application.  This  information  will  ensure  that 
those  responsible  for  implementing  the  results  of 
the  study  are  aware  of  their  availability.  This 
will  allow  them  to  tailor  their  simulation  deci¬ 
sions  accordingly. 


BASELINE  FOR  DEFINITION  AND  INCORPORATION 
OF  SIMULATORS  IN  TRAINING 

As  stated  earlier,  the  objectives  of  the 
study  were  to  determine  those  training  require¬ 
ments  in  the  combat,  combat  support  and  combat 
service  support  fields  which  could  be  enhanced 
through  the  use  of  simulation,  and  determine  a 
prioritized  listing  of  recommended  generic-type 
simulation  devices  which  would  be  capable  of 
satisfying  those  requirements.  To  this  end,  a 
number  of  data  lists,  to  be  found  in  Reference  1, 
were  developed  which  provide  a  basis  for  future 
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Marine  Corps  efforts  to  define  and  incorporate 
simulation  concepts  in  training.  Of  specific 
interest  are: 


•  Prioritized  list  of  generic  simulation  con¬ 
cepts  and  corresponding  prioritized  list  of 
task  training  requi remerits  for  each  concept. 


•  Inventory  of  simulator/training  devices  cur¬ 
rently  available,  in  development  or  planned. 

•  Overall  task  list  and  list  of  tasks  assessed 
to  be  improvable  by  simulation. 

•  Results  of  needs  assessment  task  and  weight¬ 
ing  factors  applied  to  criteria  used  in 
prioritizing  the  requirements/concepts 
matrix. 

•  Prioritized  list  of  task  training  require¬ 
ments  by  field  and  corresponding  prioritized 
list  of  generic  simulation  concepts  for  each 
task. 


Table  7  presents  a  summary  of  the  results  in 
terms  of  the  top  ranked  simulation  concepts  by 
mission  area.  The  results  are  shown  for  both 
common-  (applicable  across  all  grade  levels)  and 
leader-  (applicable  to  NCO/officer  grade  levels) 
oriented  task  training  requirements.  The  fourth 
column  of  summary  results  shows  the  percentage  of 
the  generalized  training  requirements  (the  actual 
number  is  shown  in  parentheses)  that  would  be 
satisfied  by  the  simulation  categories  shown. 

The  fifth  column  shows  the  percentage  of  task 
requirements  within  the  top  40  percentile  of 
prioritized  tasks  which  are  satisfied  by  the 
simulation  categories  shown.  The  last  column 


Table  7 

Prioritized  Listing  of  Generic  Simulation  Technology 


(1)  For  Comtion  Generalized  Task  Training  Requirements  bv  Mission  Area 

?  WEIGHTED 

GENERIC 

°o  GENERALIZED 

GENERALIZED 

OCCUPATIONAL 

MISSION 

SIMULATION 

TECH. 

TRAINING 

TRAINING 

FIELD  MOSs 

AREA 

TECHNOLOGY 

RANK 

REQUIREMENTS 

REQUIREMENTS 

TRAINED 

(SEE  TABLE  4) 

SATISFIED 

SATISFIED  BY 

(SEE  TABLE  1) 

TOP  40  PERCENTILE 

L 

1 

VDM 

2 

65 

48 

Combat 

OM 

3 

(87/131) 

(29/60) 

03,  08,  18 

IR 

4 

Combat 

OM 

1 

76 

49 

Support 

TGM/TGC 

2 

(64/85) 

(19/39) 

02,  13,  26 

Combat 

OM 

1 

72 

41 

04,  11,  13,  21, 

Service 

EMM 

2 

23,  25,  28,  34, 

Support 

VDM 

3 

(185,  256) 

(52/125) 

35,  40,  57,  58 

(2)  For  Leader  Oriented  Generalized  Task  Training  Requirements 

by  Mission  Area 

Combat 

TGM/TGC 

1 

97 

45 

03,  08,  18,  99 

TB 

_ 

2 

(90/103) 

(19/42) 

Combat 

TGM/TGC 

1 

100 

44 

13,  26,  99 

Support 

TB 

2 

(33/33) 

(6/14) 

Combat 

Service 

TGM/TGC 

TB 

1 

88 

(65/75) 

52 

04,  13,  25, 

Support 

2 

(16/31) 

57,  99 

shows  the  occupational  fields  within  each  mission 
area  that  can  be  trained  with  the  simulation 
categories  shown. 

From  the  results  shown  and  the  data  base 
developed,  the  following  conclusions  can  be 
reached: 


Technolog 


•  Majority  of  simulation  needs  can  be  met  by 
existing  technology  and/or  improvements  to 
existing  technology. 


•  Trends  are  developing  toward: 


--"Families"  of  devices  using  common 
simulation  technology  (e.g.,  panel-type 
trainers) . 


--the  occupational  fields  of  Infantry  (03), 
Field  Artillery  (08)  and  Land  and 
Amphibian  Tractor  (18)  predominate  in 
both  the  common-  and  leader-oriented 
combat  mission  area  tasks. 

--the  occupational  field  of  Engineer, 
Construction,  Equipment  and  Shore 
Party  (13)  is  predominant  in  both  the 
common-  and  leader-oriented  combat 
support  and  combat  service  support 
mission  area  tasks. 

--mission-oriented  tasks  have  the  most 
shortfall  of  all  leader-oriented  task 
training. 


FUTURE  USE 


--Games,  both  manual  and  computerized, 
for  common-  and  staff- type  task  training 
functions. 


--Shift  in  emphasis  from  few  devices 
located  in  formal  schools  to  multiple 
devices  for  sustainment  training. 

•  NBC  simulation  technology  is  currently  lim¬ 
ited,  but  development/planned  programs  are 
progressing.  NBC  simulation  is  difficult  to 
achieve  by  the  nature  of  the  task. 


Dual i ty-of-Trai ni ng 


•  The  quality-of-training  of  V%  of  all  tasks 
In  the  combat,  combat  support,  and  combat 
service  support  fields  can  be  improved  by  the 
use  of  simulation. 


•  No  technology  concepts  could  be  identified 
for  a  number  of  tasks  which,  otherwise,  would 
have  been  improved  by  simulation.  These 
tasks  should  be  reviewed  at  regular  intervals. 


In  order  to  provide  an  explanation  of  how 
this  study  will  be  used  by  the  Marine  Corps  it  is 
necessary  to  introduce  two  on-going  efforts  of 
considerable  impact. 

The  first  of  these  efforts  is  in  the  realm  of 
front  end  analysis.  The  Marine  Corps  has  recently 
begun  an  effort  to  develop  documented  training 
standards  for  individuals.  That  effort  is  now 
underway  and  as  portions  of  it  are  completed  they 
will  be  subject  to  this  study's  findings. 

The  second  effort  is  a  program  titled  the 
Training  Resource  Initiative  Program  (TRIP).  TRIP 
was  developed  to  solicit  input  from  trainers, 
training  managers  and  commanders  at  all  levels. 
That  input  is  requested  in  the  form  of  deficien¬ 
cies  or  areas  in  which  training  is  not  conducted. 
Respondents  have  been  directed  not  to  consider 
resources,  environmental  or  political  restraints 
as  they  develop  their  input.  They  have  been 
further  directed  to  prioritize  their  submissions 
in  terms  of  the  stated  deficiencies’  impact  on 
mission  accomplishment. 


Evaluation  of  Requirements/Concepts 


•  No  constraints  were  found  for  the  generic 
simulation  concepts  of  interest  that  would 
preclude  or  hinder  integratability  with 
training. 


Prioritization  of  Requirements/Concepts 


t  Results  obtained  are  based  on  the  established 
criteria  and  the  weight/rating  level  assigned. 
As  these  are  refined,  reevaluation  of  the 
prioritization  may  be  required. 


0  The  prioritization  of  generalized  task 
training  requirements  ordered  by  decreasing 
Importance  relative  to  training  needs  shows 
that. 


Therefore,  the  first  of  these  efforts  will 
produce  training  standards  which  will  be  used  to 
refine  the  evaluation  of  simulation  support  needs 
in  training.  In  addition,  the  task  analyses  that 
are  conducted  in  order  to  develop  training  stan¬ 
dards  will  be  used  to  refine  what  is  now  a  generic 
effort  and  give  it  specificity  necessary  for  the 
most  effective  identification  of  appropriate 
training  medium.  There  is  a  third  value  to  the 
identification  of  training  standards  and  that  is  a 
form  of  feedback  not  now  available.  With  a  stan¬ 
dard  for  performance  we  can  document  the  now 
generically  approved  technology  to  a  degree  not 
presently  possible.  With  that  documentation, 
reordering  of  the  recommended  technologies  or 
further  substantiation  of  their  present  order  will 
be  possible. 
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The  interface  with  the  second  effort,  TRIP, 
is  expected  to  provide  a  more  immediate  return. 
With  documented  evidence  of  the  value  and  cost 
benefit  various  technologies  can  afford  identified 
training  requirement,  the  results  of  the  study  can 
be  applied  directly  by  resource  managers  in  de¬ 
veloping  plans  to  respond  to  identified  deficien¬ 
cies. 

In  summary,  the  Marine  Corps  will  use  this 
effort  as  a  dynamic  tool  of  particular  value  to 
the  resource  manager  as  he  seeks  to  provide  the 
most  effective,  efficient  media  for  training,  and 
to  the  trainer  as  he  seeks  to  identify  the  most 
definitive  means  to  measure  training  program 
effectiveness. 


REFERENCES 

1.  "Marine  Corps  Simulator  Training  Needs  in  the 
1985-1995  Timeframe,"  Report  8482/BUF-55, 
Falcon  Research  and  XMCO,  Inc.,  Vols.  I,  II, 

&  III,  January  1983. 

2.  "Interservice  Procedures  for  Instructional 
Systems  Development,"  TRADOC  Pamphlet  350-30. 


ACKNOWLEDGEMENTS 

This  study  was  performed  by  the  team  of 
Falcon  Research  as  the  Prime,  and  XMCO,  Inc.  as 
the  Subcontractor.  Mr.  Paul  Patti  was  project 
engineer.  Messrs.  Leon  Regent  and  Joseph  Paluh 
(LTC,  US  Army,  Ret.),  from  Falcon  and  XMCO  re¬ 
spectively,  were  task  leaders  and  chief  investi¬ 
gators  for  the  effort  performed  by  each  team 
member. 

The  Marine  technical  moni tors--Majors  T.  Dunn 
and  J.  Hughes  (MCDEC),  and  Major  J.  Marlin  (HQMC)-- 
provided  assistance  and  guidance  throughout  the 
study. 


Mr.  Paul  Patti  is  a  Senior  Research  Engineer 
and  Deputy  Director  of  the  Falcon  Research  facility 
in  Buffalo,  New  York.  He  holds  B.E.E.  and  M.S. 
degrees  in  Electrical  Engineering  from  New  York 
University.  In  prior  associations,  he  was  con¬ 
cerned  with  electronic  countermeasures  for  air¬ 
craft  survivability  while  at  Calspan  (formerly 
Cornell  Aeronautical  Laboratory,  Inc.)  and  at 
Fairchild  Republic  Company  he  was  responsible  for 
F-15  air-to-air  simulations  and  effectiveness 
studies  of  the  A- 10  aircraft. 

Major  J.  (Jeff)  Marlin  is  currently  the  Head 
of  the  Training  Support  Requirements  Evaluation 
Division  of  the  Marine  Corps  Training  and  Audio¬ 
visual  Support  Department  at  Quantico,  Virginia. 

He  is  a  graduate  of  the  U.S.  Naval  Academy, 
Annapolis,  Maryland  and  has'  completed  over  fifteen 
years  of  command  and  staff  assignments. 


AD-P003  466 


CHANGING  ART  I  LLERY  TRAINING  REOUT  REMKNTS 


7^ 

Chris  Savinell;  I  ini  Taylor 
AA1  Corporation 
Cockeys  v  i  1  1  e  ,  Maryland 


ABSTRACT 

The  modern  battlefield  has  created  a  need  for  new  artillery  tactics  and  equipment.  The 
need  to  fight  a  sustained  battle  in  a  nuclear,  biological  and/or  chemical  (NBC)  environment 
while  maintaining  high  mobility  is  a  substantial  challenge,  New  HELP  and  DSWS  Self  Propelled 
Howitzer  (SPH)  configurations,  combined  with  laser  rangefinders  and  computers  promise  signi¬ 
ficant  Increases  in  artillery  effectiveness  and  efficiency.  Revised  tactics  and  equipment 
dictate  new  artillery  training  requirements.  Digital  data,  on-hoard  navigation  and  automatic 
fire  control  systems  are  now  included  in  the  primary  operating  modes.  The  responsibilities 
and  technical  capabilities  of  personnel  are  ('hanging.  The  challenge  is  to  provide  effective 
training  from  individualized  classroom  instruction  through  integrated  live  fire  exercises. 

INTRODUCTION  requirements  of  the  modern  battlefield  and  the 

resultant  new  equipment  under  development  are 


In  the  past,  live-fire  training  was  the 
primary  training  method  for  the  howitzer  crew. 
The  reasonable  cost  and  availability  of 
ammunition,  fuel  and  other  resources  and  the 
comparative  simplicity  of  the  SPH  systems  pro¬ 
vided  a  strong  argument  for  this  method  of 
training.  A  number  of  changes  have  occurred  and 
are  occurring  which  alter  this  situation.  The 
modern  battlefield  has  become  more  hostile  and 
complex  than  in  the  past.  Inflation  and  the  high 
turnover  of  skilled  personnel  have  combined  to 
make  live  fire  training  far  less  cost  effective 
than  in  the  past.  Also,  the  Army  is  developing 
new  equipment  and  methods.  Some  advanced  pro¬ 
totype  systems  have  already  been  fielded. 

Now  that  some  of  the  specialized  and  diverse 
training  requirements  for  these  new  systems  are 
understood,  the  emphasis  on  alternate  training 
and  simulation  techniques  has  grown.  As  more  and 
more  of  the  advanced  artillery  systems  are 
fielded,  training  will  be  accomplished  with  a 
combination  of  live  fire  exercises  and  special¬ 
ized  trainers  and  simulators.  "Closed  loop," 
integrated  system  training  as  well  as  individual 
unit  training  will  use  these  special  devices. 
Trainers  and  simulators  will  not  eliminate  live 
fire  training  hut  will  make  overall  training  more 
thorough  as  well  as  cost  effective. 

Following  a  discussion  of  changing  require¬ 
ments,  new  training  considerations  will  he 
addressed  using  howitzer  crew  training  as  an 
example . 


CHANCING  REOUI  RRMF.NTS 

As  evident  in  the  recent  Middle  Fast 
conflicts,  battlelines  and  battlefield  positions 
have  become  increasingly  dynamic.  Tn  future 
conflicts,  the  artillery  mobility  will  he  of  the 
utmost  importance.  The  potential  for  a  warfare 
environment  requiring  NBC  protection  adds  vet 
another  layer  of  complexity  to  the  problem 
through  the  possible  contamination  of  both  the 
firing  batteries  and  supply  systems.  The 


placing  different  requirements  upon  artillery 
personnel  . 

Modern  Battlefield  Environment 

o  NBC  (Nuclear,  Bio.,  Chem.  Contamination) 

o  HIGH  MOBILITY 

o  EARLY  ROUND  ACCURACY 

Operations  in  an  NBC  environment  require 
protective  shelters,  sealed  vehicles,  and/or 
protective  clothing.  Routine  tasks  become  diffi¬ 
cult  and  often  exhausting  when  performed  in 
protective  clothing.  Tasks  such  as  artillery 
ammunition  handling  are  extremely  difficult  when 
significant  fire  rates  are  involved.  Much  of  the 
new  equipment  under  development  will  incorporate 
features  designed  to  improve  operation  in  the  NBC 
environment.  For  example,  the  Human  Engineering 
Laboratory  is  developing  an  experimental  Command 
Post  Vehicle  which  is  secure  against  contami¬ 
nants,  thereby  permitting  the  crew  to  operate 
inside  the  vehicle  without  individual  protective 
clothing.  While  equipment  of  this  type  enhances 
the  crew's  ability  to  function  in  an  NBC  envi¬ 
ronment,  it  may  introduce  additional  stress 
factors  associated  with  confined  living  spaces. 
It  is  not  difficult  to  see  that  these  new  operat¬ 
ing  conditions  will  influence  the  Lvpe  and  extent 
of  training. 

For  generations,  mobility  has  been  a  steadily 
increasing  parameter  of  the  battlefield  environ¬ 
ment.  High  mobility  for  artillery  units  creates 
many  new  problems  in  terms  of  coordination  of 
command  and  control  ,  setup  of  secure  communica¬ 
tion  networks,  reconnaissance,  selection  of 
position,  and  development  of  reliable  ammunition 
resupplv  techniques.  Establishing  rendezvous 
points  for  resupplv  vehicles  is  hut  one  element 
of  the  mobility  problem  for  which  training  will 
he  necessary. 

Accurate  earlv  round  fire  will  become  essen¬ 
tial  if  our  artillery  units  are  to  avoid 
conn t erat 1  ark  resulting  from  cnemv  fire-finder 
radars.  Accuracy  and  quick  response  are 
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general  Iv  conflicting  reqv\irements  implying  a 
need  for  special  training. 


NEW  THAI  N  INC  CONS  IDE RAT  1  <  >NS 


New  Equipment 


o  MULE/PTL  (Laser  Ranging  and  Designation) 
o  BCS/TACFIRE  (Computerized  Fire  Control) 
o  DMD  (Digital  Message  Device) 
o  HELP  (Howitzer  Extended  Life  Prog) 
o  DSWS  (Div.  Support  Weapon  Sys.) 
o  STNCOARS  (Comm.  Equipment) 

As  a  result  of  the  requirements  of  the  modern 
battlefield,  the  Army  is  producing  and  developing 
many  new  equipments  and  systems.  Advances  in 
materials  and  microelectronics  have  made  possible 
the  Battery  Computer  System  (BCS),  on-hoard  navi¬ 
gation  and  many  other  tactical  equipments.  Even 
more  advanced  concepts  and  prototype  equipment 
have  been  evaluated  in  the  recent  HELBAT  tests. 

The  next  generation  of  howitzer  systems,  now 
in  the  development  stages,  will  include  many 
ordnance-related  and  computer  based  improvements. 
The  M109  HELP  howitzer,  which  will  soon  he  in 
production,  incorporates  on-board  navigation  and 
electronic  fire  control  displays  for  the  first 
time.  An  integral  part  of  the  HELP  howitzer 
system  is  the  Field  Artillery  Ammunition  Supply 
Vehicle  (FAASV)  which  provides  armored  ammunition 
resupply  in  the  forward  areas.  The  DSWS  howitzer 
configuration  is  expected  to  extend  *!:e  ?mprove- 
ments  of  the  HELP  configuration  w  h  the 
incorporation  of  automatic  loading  and  a  fully 
automated  fire  control  system  with  on-board 
ballistic  calculations.  New  cannon  launched 
guided  projectiles,  rocket  assisted  projectiles, 
and  nuclear  projectiles  are  enhancing  the  artil¬ 
lery’s  accuracy,  range,  and  destructive  power. 
Jam-resistant  communication  equipment,  such  as 
SINCGARS,  will  interconnect  the  various  units. 

The  development  of  the  many  new  equipments 
creates  a  number  of  opportunities  for  new  tactics 
and  strategies  for  artillery  fire.  In  general, 
artillery  units  will  he  much  more  mobile  than  in 
the  past.  Also,  the  on-board  capabilities  of  the 
howitzer  create  a  potential  for  more  autonomous 
operations  by  individual  units.  Tving  all  of  the 
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new  equipments  and  tactics  together  will  be  C 
strategies  designed  to  increase  the  responsive¬ 
ness  of  artillery  in  the  total  battlefield 
situation. 

The  improvements  cited  above  are  specifically 
designed  to  increase  the  accuracy  and  reduce  the 
time  required  to  place  artillery  fire  on  speci¬ 
fied  targets.  In  many  cases,  there  is  also  a 
large  emphasis  on  computer  based  digital  system 
operations. 


There  are  a  number  of  aspects  of  new  training 
considerations: 

o  PERSONNEL 

Capabi 1 i t ies 
Turnover 

o  FACILITIES 
Ranges 

Training  Devices 

o  MATERIEL 

Equipment 
Ammuni t ion 
Fuel 

o  TIME 

Training  Intervals 
Time  Limitations 

o  INTEGRATION 

Unit  Elements 
Closed  Loop 
Combined  Arms 

Effective  artillery  fire  depends  upon  the 
coordinated  efforts  of  a  number  of  different 
elements  within  an  artillery  division.  Forward 
observer.  Fire  Support  Team  (FTST),  fire  direc¬ 
tion  center,  ammunition  supply  system  and 
howitzers  must  function  as  a  team  while  maxi¬ 
mizing  individuals  skills.  This  is  analogous  to 
a  baseball  team  where  each  separate  plav  depends 
on  the  indivdual  skills  of  a  few,  but  the  overall 
effectiveness  depends  upon  the  entire  team. 
Therefore,  artillery  training  must  first  address 
the  skills  of  individual  elements  and  th^n 
provide  for  integrating  more  and  more  of  the 
entire  team  in  closed  loop  and  combined  arms 
training . 

Training  for  the  next  generation  howitzer 
crew  element  is  used  as  an  example  to  illustrate 
new  considerations  necessary  for  artillery  train¬ 
ing.  Operators  and  crews  for  other  elements, 
such  as  the  FIST  units  and  fire  direction  ren¬ 
ters,  will  require  similarly  revised  individual 
training.  Some  of  the  training  considerations 
which  arise  when  an  individual  howitzer  is  inte¬ 
grated  into  batterv  closed  loop  training  are 
addressed  later  in  this  paper. 

Howitzer  Crew  Training 


n  CREW  MEMBERS  KNOW  MULTI P1.F  TASKS 


o  IMPROVED  CLASSROOM  AND  DRY  FT  RE  TRAINING 


o  CLOSED  LOOP  TRAINING 


o  TRAIN  ON  OWN  EQUIPMENT 

o  MORE  EFFICIENT  LIVE  FIRE  TRAINING 

o  REFRESHER  TRAINING 

To  establish  the  framework  in  which  crew 
training  must  be  considered,  we  first  look  at  the 
specific  aspects  of  individual  crew  operations. 
It  is  desirable,  if  not  a  requirement,  that  more 
than  one  crew  member  know  how  to  perform  a  given 
task.  Hence,  individual  training  must  be 
repeated  several  times  to  achieve  proficiet.cy  in 
the  entire  crew.  At  the  same  time,  the  costs  of 
live  fire  training  are  significant  and  many  of 
the  ranges  have  distance  restrictions  which,  in 
turn,  force  propellent  charge  zone  restrictions. 
These  factors  all  point  toward  increasing  the 
effectiveness  of  classroom  and  dry  fire  training 
in  order  to  maximize  the  usefulness  of  range  time 
and  minimize  costs.  It  should  be  recognized  that 
while  improved  classroom  and  dry  fire  training 
will  reduce  requirements  for  live  fire  training, 
it  will  never  eliminate  live  fire  training 
entirely. 

Another  factor  affecting  methodology  is  the 
level  of  proficiency  which  each  crew  member  must 
have  before  closed  loop  battery  training  can  be 
conducted  efficiently.  Here,  by  closed  loop  we 
mean,  for  example,  integrating  a  forward  obser¬ 
ver,  FIST,  battery  computer  system,  and  howitzer 
crew  into  an  operational  loop  which  delivers  fire 
onto  a  target  area  and  adjusts  fire  according  to 
forward  observer  inputs.  A  recent  demonstration 
at  Ft.  Sill  has  shown  that  training  devices 
developed  for  individual  unit  elements  can  be 
combined  to  accomplish  closed  loop  training, 
including  the  firing  of  full  caliber  training 
rounds.  Efforts  are  currently  underway  to  estab¬ 
lish  detailed  training  goals,  including 
assessment  and  scoring  methods  for  this  type  of 
training. 

There  are  two  other  factors  which  must  be 
evaluated  in  considering  training  methodology. 
One  has  to  do  with  the  equipment  itself,  the 
other  with  any  ancillary  training  equipment. 
First ,  it  is  desirable  for  a  crew  to  train  with 
its  own  equipment.  The  peculiarities  of 
operation  are  then  thoroughly  understood  by  the 
crew  and  do  not  present  surprises  should  they 
need  to  use  the  equipment  in  either  evaluation  or 
combat.  Second,  crew  training  equipment  should 
be  designed  so  that  it  can  be  removed  from  the 
host  equipment  or  is  embedded  in  the  host. 
Embedded  training  equipment,  especially  in  the 
case  of  embedded  training  software,  can  be  made 
completely  transparent  to  the  user.  In  either 
case,  the  training  realism  is  enhanced  by  using 
the  crew’s  actual  combat  equipment. 

A  number  of  trade-offs  will  exist  as  to  how 
and  where  training  is  conducted.  The  extent  of 
training  In  the  classroom  vs.  dry  fire  or  live 
fire  training  will  depend  very  much  on  the  equip¬ 
ment  for  which  the  training  is  required.  For 
example,  classroom  training  can  accomplish  much 
of  the  training  required  to  teach  personnel  to 
use  keyboards  and  displays,  as  well  as  some 
elements  of  navigation  and  map  reading.  However, 


there  will  never  be  a  complete  substitute  for  the 
actual  use*  of  the  navigation  svstem  and  maps  to 
navigate  a  howitzer  from  one  location  to  another. 
A  special  feeling  exists  when  a  crew  is  put  into 
it's  howitzer  for  the  first  time  to  navigate  to  a 
distant  point.  Emerging  from  the  vehicle  thev 
will  be  happy  or  shocked  depending  upon  where 
they  find  themselves. 

Training  methodologies  must  also  take  into 
account  training  for  proficiency  through 
refresher  courses  at  schools  and  in  field  exer¬ 
cises.  Training  for  some  specific  howitzer 
subsystems  illustrate  training  needs. 


o  FIRE  CONTROL  &  NAVIGATION 
Automatic  Modes 
Monitoring  and  Malfunction 
Ident i f icat ion 
Recal ibrat ion 
Map  Reading 
Back-up  Modes 

o  RESUPPLY 

o  TRAINING  ROUNDS 

o  NBC  TRAINING 

Decontamination 
Individual  &  Collective 
Protection 

Fire  control  systems  for  howitzers  are 
rapidly  progressing  from  fully  manual  to  fully 
automatic  systems.  The  HELP  howitzer  configura¬ 
tion  represents  an  intermediate  stage  of 
automation.  The  gun  tube  orientation  in  space  is 
determined  electronically,  but  the  drive  system 
for  gun  tube  pointing  is  controlled  manually. 
Except  for  back-up  mode  operation,  the  manual 
inputs  to  the  onboard  fire  control  system  have 
been  replaced  by  automatic  digital  data  inputs. 
The  DSWS  configuration,  in  concept  development, 
is  expected  to  have  a  fully  automatic  fire 

control  system  where  digital  data  from  a  remote 
location  may  initiate  loading,  gun  tube  pointing 
and  firing  of  the  howitzer. 

As  fire  control  functions  are  transfered  from 
manual  to  automatic  operation,  the  responsibili¬ 
ties  of  the  crew  members  also  change  from  one  of 
performing  the  weapon- 1 ayi ng  operation  to  svstem 
monitoring  and  malfunction  identification.  New 
training  courses  will  therefore  emphasize  these 

latter  monitoring  and  recognition  tasks  as 
opposed  to  manual  dexterity  and  pointing  accuracy 
tasks.  Proper  use  of  BITE  and  diagnostic 

routines  are  among  those  new  subjects  to  be 

included  in  training.  Identification  of  malfunc¬ 
tions  and  selection  of  proper  back-up  modes  (with 
knowledge  of  the  associated  amount  of  system 
degradation)  will  be  a  major  part  of  the  new 
training.  Because  some  kind  of  manual  back-up 
fire  control  will  exist  at  least  for  the  fore¬ 
seeable  future,  training  for  manual  operation 
will  not  disappear  from  the  curriculum.  Training 
for  the  new  automated  fire  control  systems  is 
expected  to  be  accomplished  by  a  combination  of 
embedded  and  stand-alone  trainers.  The 
assessment  parameters  and  scoring  for  these  new 
tasks  must  he  developed  if  training  is  to  be 
truly  effective. 


On-board  navigation  will  appear  first,  in 
artillery  systems  in  the  HELP  howitzer.  The 
on-board  navigation  systems  will  he  largely 
transparent  to  the  crew  and  will  automate  the 
majority  of  the  navigation  task.  Among  the  new 
training  tasks  will  be  field  re-ca 1 ihrat i on  at 
known  survey  points,  coordination  of  map  readings 
and  visual  observations  with  navigation  system 
data,  interpretation  of  diagnostic  routines  and 
selection  of  firing  locations.  It  should  he 
noted  that  the  more  independent  or  autonomous  the 
operation  of  the  given  howitzer,  the  greater  will 
be  the  responsibility  for  navigation.  Depending 
upon  the  organization  of  artillery  batteries  with 
this  new  equipment,  both  fire  control  and  naviga¬ 
tion  tasks  nav  create  higher  levels  of  authority 
and  responsibility  for  the  Chief  of  Section,  as 
compared  to  current  operating  methods.  As  with 
the  new  automated  fire  control  systems,  training 
for  the  on-board  navigation  systems  will  require 
a  combination  of  embedded  training  capability  and 
stand-alone  driver/section  chief  trainers. 

Both  the  HF.LP  and  DSWS  configurations  anti¬ 
cipate  a  one-on-one  operation  between  a  resupply 
vehicle  and  the  self-propelled  howitzer.  Operat¬ 
ing  in  this  one-on-one  mode,  much  of  the 
ammunition  handling  will  he  performed  inside  the 
resupply  vehicle  including  fuzing,  removing 
propellent  from  containers  and  selection  of 
projectile  types.  While  refinements  such  as  the 
introduction  of  stick  propellents  will  modify  the 
tasks  somewhat,  they  will  not  he  largely  dif¬ 
ferent  from  the  tasks  presently  performed  by  the 
ammunition  handlers  in  the  howitzer  crew.  A 
significant  difference  will  be  that  tasks  are 
performed  in  a  limited  space  inside  the  resupply 
vehicle.  Quick  response  to  mission  changes  may 
be  more  difficult  inside  the  vehicle  where  pre¬ 
viously  prepared  rounds  may  be  in  the  way. 

It  has  always  been  difficult  to  incorporate 
ammunition  handling  into  crew  training  because 
the  howitzer  could  not  be  fired.  The  flow  of 
ammunition  through  a  howitzer  is  normally  only 
one  way,  and  training  which  introduces  any  return 
flow  of  projectiles  and  propellent  is  not 
entirely  effective,  especially  when  trying  to 
simulate  rapid  fire  missions.  The  Field  Artil¬ 
lery  Shootable  Practice  Round  (FASPR),  now  under 
development,  showed  great  promise  in  the  recent 
demonstration  at  Ft.  Sill.  It  is  full  size,  vet 
requires  minimum  range  facilities.  Further,  the 
projectile  is  reuseable  and  needs  verv  little 
propellant.  Combined  with  a  recoil  simulator, 
also  under  development,  most  of  the  training 
requirements  can  now  he  met.  Training  for  shoot 
and  scoot  type  missions  will  require  such  a 
shootable  practice  round  to  facilitate  thorough 
training. 

Other  types  of  training  rounds,  such  as  the 
copperhead  and  nuclear  training  rounds,  require 
the  crew  to  unpack,  inspect,  initialize  and  load 
a  full  size  mock-up  of  the  actual  round. 

Among  the  new  training  considerations 
relevant  to  operations  in  an  NBC  environment  are 
the  following:  familiarization  with  individual 
protective  clothing,  performance  of  mission  tasks 
In  confined  spaces  over  long  periods  of  time, 
clean-tip  of  contaminated  equipment  and  material, 
field  maintenance  of  equipment  without  incurring 


contamination,  understanding  <>f  nurlear  blast 
induced  equipment,  damage  and  special  t  ictics  for 
the  NBC  battlefield. 

Integration  of  a  Howitzer  Crew  With  other  Battery 
and  Division  Level  Elements 

o  RATTKRY  COMMl'NICATION 

o  RECIPROCAL  I. AY  INC 

o  RESUPPLY  RF.NDE'/Vnns 

O  COORDINATED  firk 

Forward  Observer 
Fire  Direction  Center 
1 

C  St  rat  eg  1 es 

o  CLOSED  LOOP  OPERATION 

o  COORDINATED  SUPPORT 
Infant  rv/ Armor 
Coordinated  Battle  Plan 

Once  a  howitzer  crew  is  capable  of  operating 
effectively  as  a  unit  unto  itself,  it  is  appro¬ 
priate  to  consider  the  training  needed  to 
integrate  the  howitzer  crew  element  into  the 
total  team.  This  integration  will  he  both 
horizontal  and  vertical  in  nature.  Horizontally, 
in  that  a  given  howitzer  must  he  integrated  with 
the  other  howitzers  of  its  battery.  Vertically, 
the  howitzers  of  a  battery  must  be  integrated 
through  the  command  and  control  structure  with 
the  Fire  Direction  Center,  TACFIRF,  forward 
observers  and  finally  in  combined  arms  configu¬ 
rations.  Spread  formations  and  high  mobility 
complicate  these  integrations.  For  example,  when 
all  the  howitzers  in  a  battery  are  located  close 
together  they  can  all  fire  on  the  same  bearing  to 
attack  a  single,  small  area  target.  In  contrast, 
when  they  are  wide  spread,  each  howitzer  will 
have  its  own  bearing  in  order  to  bring  the  com¬ 
bined  fire  onto  a  single  target.  Direct, 
personal  communication  between  all  the  guns  in 
the  battery  may  not  he  possible. 

Integration  of  howitzers  in  new  spread 
battery  formations  will  first  require  training  in 
communication.  If  the  howitzers  are  operated  in 
pairs,  this  will  mean  establishing  communication 
among  the  various  pairs,  which  mav  not  he 
possible  with  l i ne-of-sight  commvmicat ions  or 
land  lines.  This  will  depend  upon  the  extent  to 
which  the  hattery  is  spread,  and  whether  or  not 
there  are  NBC  environmental  constraints.  Each 
howitzer  in  the  battery  must  he  linked  to  the 
appropriate  Fire  Direction  Center  ( F  DC ) ,  but 
direct  common i c a t i on  among  the  howitzers  is 
highlv  desirahle.  Horizontal  integration  must 
also  provide  for  operation  when  the  enemy  uses 
jamming  to  interrupt  radio  communications,  or 
damages  a  howitzer's  electronics.  In  the  latter 
situation,  reciprocal  laying  techniques  mav  he 
necessary  to  maintain  the  firing  capability  of  a 
damaged  howitzer.  Horizontal  Integration  also 
requires  interfaces  and  coordination  between  the 
howitzers  and  ammunition  resupply  vehicles. 
Depending  on  the  battlefield,  an  armored, 
resupplv  vehicle,  mav  service  one  or  more  how¬ 
itzers.  During  shoot  and  scoot  tactics 
rendezvous  points  and  timing  for  resupplv  will 


become  critical  considerations  In  battery 
operat Ion. 

In  terms  of  vertical  Integration,  the  how¬ 
itzer  crew  Is  currently  tied  through  the  FDC  to 
the  Tactical  Fire  Direction  (TACFIRF)  System. 
Recent  field  tests  showed  that  the  time  required 
from  an  initial  call  for  fire  until  rounds  impact 
the  target  can  be  reduced  substantially  if  the 
forward  observer  is  in  direct  communication  with 
the  Fire  Direction  Center.  Current  studies  are 
evaluating  a  number  of  optional  paths  of  command 
and  control  to  improve  the  effect  iveness  of  an 
artillery  battalion  in  its  overall  operation. 
One  can  readily  imagine  that  no  single  arrange¬ 
ment  will  be  the  best  for  all  possible  artillery 
support  roles.  Consequently,  training  methods  at 
this  level  will  need  to  incorporate  lessons  or 
simulations  which  train  personnel  to  use  the  most 
appropriate  command  and  control  strategy.  Coor¬ 
dinate  transformation,  reference  point 
recognition,  accurate  message  transmission  and 
geographical  barriers  all  have  implications  in 
terms  of  successful  integration  of  the  complete 
artillery  unit.  There  is  also  a  very  clear  con¬ 
nection  between  the  factors  which  affect 
artillery  integration  and  the  correspond i ng 
training  methods  and  equipment. 

A s  an  example  of  vertically  integrated  train¬ 
ing,  consider  the  closed  loop  training  concept 
mentioned  earlier.  Forward  observers  (FO),  gun 
crews  and  FDC  operators  are  trained  individually 
with  the  Training  Set  Forward  Observer  (TSFO), 
Artillery  Firing  Battery  Trainer  (AFBT)  and  BCS 
training  software,  respectively.  Then,  these 
trainers  are  interfaced  to  one  another  via  appro¬ 
priate  communication  and  data  links  to  form  a 
loop.  The  FO  observes  a  target  on  his  TSFO  and 
calls  for  fire  support.  FDC  personnel  receive 
the  request  and  transmit  orders  to  each  gun  crew. 
The  gun  crews  lay  their  operational  howitzers, 
load  and  fire  FASPR  ammunition  while  the  AFBT 
monitors  each  crew  and  transmits  actual  results 
back  to  the  TSFO.  "Would  hit"  coordinates  are 
used  to  locate  burst  signatures  in  real  time  on 
the  TSFO  screen.  The  FO  can  then  initiate  cor¬ 
rections  as  necessary  and  then  fire  for  effect. 
The  closed  loop  concept  can  he  applied  to  any  of 
the  command  and  control  loops  found  in  artillery 
operations.  Current  efforts  are  directed  to 
field  trials  of  the  concept  with  existing  equip¬ 
ment  and  an  evaluation  of  the  effectiveness  of 
this  type  of  training  as  compared  to  classroom 
and  live  fire  exercises. 

Combined  arms  training  is  also  necessary. 
This  is  yet  a  higher  level  of  integrated  training 
in  which  the  artillery  unit  is  cooperating  with 
infantry  and  armor  units  to  learn  complete 
battlefield  strategies.  The  effectiveness  of 
combined  arms  training  will  depend  heavily  upon 
the  effectiveness  of  the  training  which  indi¬ 
vidual  units  receive  prf^r  to  ioining  a  combined 
exercise.  At  this  level  there  is  a  need  to 
simulate  artillery  fire  without  danger  to  the 
troops  involved.  When  the  artillery  is  support¬ 
ing  the  infantrv  it  must  place  cannon  fire  over 
and  just  in  front  of  the  advancfng  troops. 
Consequent  1  v ,  the  safety  reqtii  rement  s  for  train¬ 
ing  are  especially  difficult.  \s  a  minimum,  some 
form  of  training  round  which  allows  the  howitzers 
to  be  fired  and  the  apparent  fall  of  shot  to  he 
computed  is  a  requirement.  (Whether  it  is 


possible  to  cre.u»-  a  training  round  with  ad*«ou -it  e 
safetv  to  he  tired  over  the  troops,  md  sjmil  u  »■ 
t  tie  hurst  of  artillery  fire  in  the  forward  area 
remains  a  challenge.)  having  errors  eunmitted  hv 
t  he  SPH  crew  can  he  measured  and  used  to  r«n;>nl.' 
the  expected  impact  coordinates.  This  informa¬ 
tion  can  he  used  to  increase  the  realism  or 
combined  arms  training  by  providing  a  real-time 
indication  of  actual  artillery  f  i  re  impact  which 
can  then  be  used  to  provide  more  realistic 
casual  t  y/d  aniage  assessment.  Coordination  of  the 
battle  maneuver  plan,  including  the  use  of  ef  <*c- 
tive  artillery,  will  be  the  primary  training  at 
this  level . 


CONCLUSIONS 

This  examination  of  new  artillery  battlefield 
environments,  equipment  and  specific  new  tasks 
for  a  howitzer  cr»w  leads  to  several  conclusions: 

1.  The  new  battlefield  environments  and 
equipment  imply  new  training  needs. 

2.  Personnel  and  cost  cons iderat i ons  point 
to  a  greater  emphasis  on  classroom  and 
dry  fire  training  to  make  live  fire 
training  more  efficient. 

3.  Crew  training  with  the  units'  equipment 
has  special  benefits  to  readiness. 

4.  Trainers  designed  for  individual  unit 
elements  can  be  interconnected  to  provide 
closed  loop  integrated  training. 

5.  Thorough  individual  element  (e.g., 
howitzer  crew)  training  prior  to  inte¬ 
grated  training  will  vield  more  efficient 
t  raining  overal 1 . 

b.  Keyboard  and  visual  display  useage,  map 
reading  and  malfunction  analysis  will  all 
be  key  training  elements. 

7.  Backup  modes  will  require  continued 
training  in  manual  operating  methods. 

Changing  artillery  training  requirements  will 
mean  revised  training  methods  supported  by  cor¬ 
respondingly  revised  training  facilities. 
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ABSTRACT 

This  paper  reports  on  a  preliminary  training  development  study  (TDS)  of  the  proposed 
training  devices  for  the  operator  course  of  the  Division  Support  Weapon  System. 

Training  device  requirements  for  this  system  are  being  determined  during  the  earliest 
stages  of  the  Life  Cycle  System  Management  Model  (LCSMM) .  The  study  overcame  the 
lack  of  data  needed  for  training  device  decision-making  by  building  upon  the  compar¬ 
ability  analysis  techniques  embodied  in  previous  applications  of  the  HARDMAN 
methodology  to  the  Division  Support  Weapon  System.  The  results  of  this  study  suggested 
that  device-based  courses  would  be  substantially  less  costly  than  equipment-based 
courses. 


INTRODUCTION 

The  basic  thrust  of  the  training  device  effort 
for  the  Division  Support  Weapon  System  (DSWS) 

{now  called  the  155mm  Self-Propelled  Howitzer 
Improvement  Program)  is  to  identify  system 
training  devices  early  enough  so  that  actual 
equipment  and  training  devices  can  be  developed 
and  fielded  concurrently.  Additionally,  under 
the  DARCOM/TRADOC  Letter  of  Agreement  (LOA) , 
the  training  for  the  first  Operational  Test  (OT  I) 
of  the  weapon  system  will  provide  for  the  inclus¬ 
ion  of  brassboard  training  devices.  in  order  to 
meet  this  schedule,  training  device  requirements 
are  being  determined  during  the  earliest  stages 
of  the  Life  Cycle  System  Management  Model 
(LCSMM)  -  earlier  than  most  other  major  Army 
systems  acquisition  programs. 

The  purpose  of  this  paper  is  to  describe  a  cost 
analysis  of  the  training  devices  proposed  for  use 
in  the  entry  level  DSWS  operator  course.  The 
study  extended  analyses  of  this  course  and 
utilized  pertinent  data  and  results  obtained 
during  previous  applications  of  the  HARDMAN 
methodology  to  DSWS. 

THE  HARDMAN  METHODOLOGY 

The  HARDMAN  methodology  is  designed  primarily  for 
front-end  analysis;  it  determines  human  resource 
requirements,  identifies  high  resource  drivers, 
and  provides  the  necessary  information  to  conduct 
human  resource/equipment  design  tradeoffs  during 
the  early  phases  of  the  Weapon  System  Acquisition 
Process  (WSAP) .  As  in  DSWS,  where  several 
competing  configurations  are  proposed,  ii  permits 
comparisons  of  the  relative  human  resource  demands 
of  each. 

The  methodology,  shown  in  Figure  1,  is  a  six-step 
process.  It  is  triggered  with  the  establishment 
of  a  consolidated  data  base  (CDB) ;  the  next 
three  steps  determine  the  demand  of  a  systems 
design,  generally  following  the  precepts  of 
comparability  analysis.  Comparability  analysis 
derives  systematic  estimates  of  human  resource 
requirements  of  a  proposed  weapon  system  by 
extrapolating  from  the  known  requirements  of 
similar,  operational  systems  and  subsystems. 


Figure  1.  Steps  in  Methodology 

One  of  the  major  constructs  of  this  analysis  is 
the  development  of  a  Baseline  Comparison  System 
(BCS)  as  described  in  MIL-STD  1388-1A,  Logistic 
Support  Analysis. CD  The  BCS  is  a  current 
operational  system,  or  more  likely,  a  composite 
of  current  operational  subsystems,  which  also 
closely  represents  the  design,  operational  and 
support  characteristics  required  for  the  system 
proposed  for  development.  in  summary,  compar¬ 
ability  analysis  forms  a  bridge  between  a  new 
system's  mission  requirements  and  its  people 
and  cost  requirements.  Further  descriptions  and 
explanations  of  the  methodology  can  be  found 

in  other  sources. <2,  3,  4) 

THE  DSWS  PROGRAM 

The  Division  Support  Weapon  System  is  envisioned 
as  a  replacement  for  the  current  M109-ser ies  of 
155mm  self-propelled  howitzers  and  the  fire 
support  system  associated  with  it.  The  concept 
is  intended  to  be  applicable  to  all  levels  of 
conflict  in  the  1990-2010  time  frame. 

The  program  is  presently  in  the  concept  formula¬ 
tion  phase  with  Army  Systems  Acquisition  Review 
Council  I  (ASARC  I)  scheduled  in  January  1984.  At 
this  stage  in  the  acquisition  process,  a  number 
of  contractor  designs  and  one  foreign  system  are 
under  cons ider at  ion .  The  HARDMAN  application 
focused  on  three  proposed  design  conf igurat ions, 
one  each  from  Norden  Systems,  Inc.,  FMC  Corp. , 


and  Pacific  Car  and  Foundry,  Inc.  i PACCAR ) .  In 
addition,  a  near-term  Product  Improvement  program 
(PIP)  alternative  was  evaluated.  The  Nor  den 
design  represented  a  maximum  product  improvement 
and  was  chosen  as  the  equipment  configuration  for 
study.  This  concept  represented  a  theoretical 
"midpoint"  between  the  existing  self-propelled 
howitzer  (SPH)  and  its  ammunition  resupply 
vehicle  (ARV)  and  a  totally  new  design.  Without 
going  into  any  specific  design  detail,  suffice  it 
to  say  that  the  bat v.efield  of  the  future  en¬ 
visioned  for  this  weapon  system  will  require 
capabilities  that  are  profoundly  different  trom 
the  existing  system.  The  improvements  in  rates 
of  fire,  mobility,  communicat ions,  fire  control, 
resupply,  navigation,  and  its  ability  to  survive 
in  future  battlefield  conditions  will  have 
dramatic  impacts  on  the  tasks  performed  by  the 
operators  and  maintainers  of  th?  existing 
weapon  system  and,  hence,  on  their  training 
programs . 

OPERATOR  INSTITUTIONAL  TRAINING  DEVICES 

The  training  device  concepts  evaluated  in  the 
study  were  those  included  in  the  DSWS  Training 
Device  Concept  Formulation  Plan  (CFP) ,  which 
was  prepared  under  the  direction  of  the  Program 
Manager  for  Training  Devices  (PM  TRADE).  This 
plan  represented  a  major  departure  from  the 
usual  pattern,  in  that  is  was  prepared  during 
the  concept  definition  pha  ?  with,  as  previously 
described,  several  candidate  concepts  under 
consideration.  As  such,  the  plan  was  justifiably 
general  in  scope  to  »ccomodate  all  of  the  pro¬ 
posed  designs. 

Two  devices  included  in  the  CFP  were  intended  for 
use  in  entry  level  institutional  training  of 
the  DSWS  operator.  These  devices  were  the  DSWS 
Institutional  Fire  Mission  Trainer  { I FMT )  and  the 
DSWS  Institutional  Driver  Trainer  (IDT).  Because 
of  the  "first-cut"  nature  of  the  CFP,  the 
operational  strategy  of  how  the  devices  were  to 
be  used  in  the  course  of  instruction  was  expanded 
in  the  study. 

Figure  2  shows  the  Institutional  Fire  Mission 
Trainer  ( I FMT )  which  consists  of  five  (5)  trainee 
stations  and  one  instructor  station.  Each  trainee 
station  consists  of  a  mock-up  of  the  DSWS  SPH 
crew  compartment.  The  IFMT  would  be  used  to  train 
SPH  crew  members  individually  or  as  a  team  in  the 
tasks  required  to  conduct  a  direct  or  indirect 
fire  mission,  including  performance  under  degraded 
condit ions. 
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Figure  2.  Institutional  Fire  Mission  Trainer 


Figure  3  depicts  the  Institutional  Driver  Trainer 
(IDT)  which  consists  of  six  (6)  trainee  stations 
and  one  instructor  station.  Three  of  the  trainee 
stations  consist  of  a  mock-up  of  the  DSWS  SPH 
driver  compartment,  and  three  wo,;  Id  represent 
the  ARV  driver  compartment.  The  IDT  will  be  used 
primarily  to  train  DSWS  SPH  and  ARV  crew  member c 
in  the  tasks  needed  to  drive  the  respective 
vehicles. 


Figure  3.  Institutional  Driver  Trainer 


DESCRIPTION  OF  STUDY  AND  METHODOLOGY 

The  major  objective  of  the  cost  analysis  was  to 
determine  the  training  and  resource  impacts  of 
using  equipment  versus  training  devices  in  the 
proposed  DSWS  operator  course.  The  trend  in 
weapon  system  acquisition  is  in  the  direction  of 
acquiring  a  smaller  number  of  more  capable  (and 
more  expensive)  weapons  that  will  be  less  avail¬ 
able  for  training.  The  DSWS  Outline  Individual 
and  Collective  Training  Plan  (OICTP)  assumed 
that  training  strategies  making  extensive  use  of 
table  of  organization  and  equipment  (TOE)  hard¬ 
ware  would  not  be  cost  effective;  hence,  an 
increased  use  of  training  devices  would  be  re¬ 
quired.  The  study  was  aimed  at  testing  this 
assumption.  Several  resources  that  are  typically 
affected  by  the  use  of  equipment  versus  training 
devices  for  operator  training  were  included  as 
follows:  (1)  fuel,  (2)  ammunition,  (3)  maintenance 
facilities,  (4)  maintenance  and  other  support 
personnel,  (5)  spare  parts,  (6)  live-firing  ranges, 
and  (7)  driver  training  areas.  Key  training 
issues  that  affected  this  study  included: 

(1)  safety  restrictions  due  to  the  operation  of 
the  automatic  loader,  (2)  need  for  more  extensive 
crew  training,  (3)  space  available  within  the 
DSWS  turret/cab  for  training,  (4)  increased 
capability  of  some  training  devices  to  facilitate 
fault  isolation  and  scenario  programming,  and 
(5)  student  to  instructor  and  student  to  equipment 
ratios. 

An  analysis  of  the  resource  impacts  of  these 
alternative  training  concepts  raised  the  following 
two  questions:  (1)  Can  training  devices  be  used 
to  lower  the  number  of  DSWS  self-propelled 
howitzers  (SPH)  and  ammunition  resupply  vehicles 
(ARV)  required  for  training  in  the  1 3B  Cannon 
Crewman  Course?  and  (2)  Are  the  training  devices 
proposed  for  the  1 3B  course  in  the  DSWS  Training 
Device  Concept  Formulation  Plan  less  costly  over 
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a  twenty  year  training  life  cycle  than  the 
operational  equipment  (assuming  fixed  training 
effectiveness  between  equipment  and  training 
dev  ices) ? 

The  study  was  conducted  in  five  steps: 

•  Updated  Operator  Course  and  Tasks 

•  Identified  Equipment  Requirements 

•  Identified  Training  Device  Requirements 

•  Conducted  Cost  Analysis 

•  Presented  Results 

Given  the  objective  of  the  study  and  DSWS  as  a 
developing  system,  the  study  constituted  a 
preliminary  Training  Development  Study  (TDS )  as 
described  in  TRADOC  Reg  350-4, (6)  TRADOC 
Cir  70-1(6),  and  the  TRADOC  Training  Effectiveness 
Analysis  (TEA)  Handbook. (^) 

DSWS  OPERATOR  TASKS 

The  DSWS  operator  tasks  were  initially  analyzed 
in  the  HARDMAN  application  and  updated  in  the 
study.  The  first  step  in  analyzing  the  DSWS 
task  requirements  was  to  identify  the  sources 
of  system-specific  task  and  course  information. 

The  Operator  Training  Source  Index  was  used  for 
this  purpose  and  provided  a  system  functional 
context  in  which  to  analyze  the  effects  of 
equipment  design  differences  on  the  operation 
of  the  total  system. 

Functional  focus  for  the  study  was  provided  by 
using  the  operational  scenario  for  the  SPH  and 
ARV  developed  in  the  HARDMAN  Functional  Require¬ 
ments  Analysis.  This  scenario  is  shown  in  Figure 
4  as  a  mission  event  profile.  Five  of  the 
functions  are  performed  in  series,  i.e.,  no  two 
of  these  functions  can  be  performed  simulta¬ 
neously.  However,  other  functions,  such  as 
command  and  control,  can  be  performed  in 
parallel,  i.e.,  simultaneously  with  any  other 
function. 


Tasks  identitied  in  the  first  step  (rum  tin- 
existing  MI09  system  were  then  analyzed.  The 
analysis  of  the  existing  tasks  identified 
(1)  which  tasks  had  to  be  deleted,  and  (2j  which 
tasks  had  to  be  modified  to  reflect  the  proposed 
system  design.  The  resulting  system-specific 
task  changes  were  then  documented  by  code  on 
Ex ist  ing  Task  Delet ion/Mod if icat ion  Wqr k s h e e t s . 
Deletion  of  a  task  may  be  indicated  for  reasons 
of  subsystem  elimination,  task  automation,  reduced 
task  frequency,  change  in  maintenance  concept, 
or  change  in  operational  concept.  Task  modifica¬ 
tions  include  minor  change  in  equipment/procedure, 
skill  level  change,  frequency  change,  or  major 
change  in  skills  and  knowledges. 

Inputs  to  this  analysis  from  the  HARDMAN  applica¬ 
tion  included  equipment  descriptions/manuals, 
engineering  functional  flow  diagrams,  engineering 
design  difference  indexes,  equipment  lists, 
engineering  equipment  configurations,  results 
from  the  reliability/maintainability  analysis, 
and  the  results  of  the  functional  and  manpower 
requirements  analyses.  Of  key  importance  to  this 
analysis  is  the  interdisciplinary  interaction  of 
manpower,  personnel,  training,  engineering  and 
systems  analysts  involved  in  defining  the  various 
system  designs  and  their  impacts. 

Existing  tasks  requiring  major  modification  and 
additional  tasks  identified  on  the  Operator 
Training  Source  Index  were  analyzed  further  on 
the  Task  Characteristic  Worksheet.  During  this 
step,  further  descriptive  information  about  the 
comparable  tasks  is  added  and  the  characteristics 
of  the  new  tasks  are  estimated.  Estimates  of 
task  difficulty,  importance,  and  frequency  (DIF) 
are  possible  in  this  analysis,  but  due  to 
uncertainties  associated  with  the  criteria  for 
selecting  tasks  for  training  and  training  settings, 
and  difficulties  involved  in  getting  proper  data 
for  the  comparable  tasks,  this  analysis  was  not 
conducted.  The  approach  used  in  this  iteration 
was  to  consider  all  tasks  identified  at  this  point 
to  be  selected  for  training  and  to  assign  the 
training  setting  and  skill  level  of  the  comparable 
task  to  the  new  task. 

A  total  of  70  skill  level  1  tasks  were  identified. 
Of  these,  15  tasks  were  determined  to  be  affected 
by  changes  in  frequency  that  may,  after  further 
analysis,  result  in  the  deletion  of  these  tasks 
from  the  course.  While  identifying  tasks  that 
would  be  trained  in  the  entry  level  operator 
course,  21  additional  skill  level  2  tasks  were 
identified.  These  tasks  represent  a  substantial 
amount  of  advanced  technical  training  that  will 
have  to  be  assigned  to  a  training  setting.  This 
future  assignment  may  drastically  affect  the  entry 
level  course. 

DSWS  OPERATOR  COURSE 
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Figure  4.  Mission  Event  Profile 


Once  the  operator  tasks  had  been  identified,  an 
entry  level  course  of  instruction  was  developed 
that  incorporated  training  for  the  skill  level 
one  tasks.  This  initial  course  was  equipment - 
based  and  incorporated  the  training  philosophy 
found  in  the  existing  M109  operate?!  (HBlO-OSUT) 
program  ol  instruction.  Using  this  course  as 
a  basis,  a  device-based  course  was  then  developed. 
The  development  of  the  device-based  course  involved 
replacing  the  SPH  with  the  appropriate  training 
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devices,  changing  equipment  to  student  and 
instructor  to  student  ratios,  removing  vehicle- 
specific  resource  requirements,  and  reducing 
commander’s  time  previously  needed  to  cover  such 
field  training  contingencies  as  weather,  and 
range  and  vehicle  availability. 

In  order  to  capture  the  vehicle  and  instructor 
resources  that  are  consumed  dur  ing  the  conduct 
of  training,  Cour se  Resou  r_ce_ Wot k shee t s  were 
developed.  These  worksheets  graphically  showed 
the  use  of  the  following  resources: 


(1) 

Hours  of 

Instruct  ion 

(2) 

Veh icles 

Used 

(3) 

Types  of 

Instruct  ion 

(4) 

Equipment 

to  Student  Ratios 

(3) 

Instructor  to  Student  Ratios 

(6) 

Instr ucto 

r  to  Equipment  Ratios 

(7) 

Miles  Traveled 

(8) 

Ammunition  Fired 

COST  ANALYSIS 

Once  the  resource  parameters  were  established, 
the  equipment  and  device  requirements  were 
determined.  Courses  were  overlapped,  where 
possible,  in  order  to  optimize  resource 
requirements.  If  courses  are  overlapped,  the 
number  of  days  between  the  starting  time  of 
successive  class  sessions  decrease  and,  therefore, 
the  number  of  sessions  per  year  increase. 

Research  and  development  ( R&D)  costs,  investment 
costs,  and  operations  and  support  (O&S)  costs 
were  then  determined  for  the  equipment  and 
device-based  courses.  These  costs  were  obtained 
from  a  large  number  of  different  sources  and 
methods.  The  most  important  sources  were  the 
DSWS  Baseline  Cost  Estimates  (BCE)  for  the 
equipment  and  the  PM  TRADE  cost  estimates  for 
the  training  devices. 

As  tradeoffs,  two  alternatives  for  the  equipment 
and  training  device  courses  were  evaluated: 

(1)  30%  Driver's  Training  -  Only  30% 
of  the  trainees  are  required  to 
complete  driver's  training. 

(2)  Double  Shift  -  In  addition  to  30% 
driver's  training,  two  shifts  of 
classes  are  held. 

RESULTS 

A  summary  of  the  significant  resource  requirements 
are  shown  in  Table  1. 

Over  a  twenty  year  life  cycle,  the  equipment- 
based  course  was  28%  higher  in  cost  than  the 
device-based  course.  In  the  30%  driver’s  train¬ 
ing  alternative,  the  equipment-based  course  cost 
was  31%  more  than  the  device-based  course, 
while  in  the  double  shift  alternative,  the 
equ l pment -based  course  cost  was  40%  more. 

These  results,  however,  are  v*  ry  sensitive  and 
are  dependent  upon  a  number  of  assumptions  in 
the  following  areas  which  must  be  precisely 
defined  in  order  to  make  a  sound  investment 
dec  1 s ion : 


Table  1.  Summary  of  Resource  Requirements 


•  Student  to  Equ ipment /Dev  ice  Ratios 

•  Class  Lengths 

•  Staggered  Usage  of  Equipment/Devices 

•  Sequencing  of  Course  Modules 

•  Number  of  Different  Equipment  Devices 
Available  for  Training 

The  cost  accounting  categories  and  procedures 
employed  at  the  training  center  level,  post 
level,  and  TRADOC  level  do  not  coincide.  Cost 
factors  identified  at  the  course  level  are 
undist ingu ishable  by  the  time  they  reach  TRADOC. 
This  negated  the  usefulness  of  the  TRADOC  course 
cost  analysis  program  as  a  tool  for  modeling 
the  costs  of  training  devices  within  courses 
of  instruction. 

CONCLUSION 

The  cost  analysis  conducted  in  this  study  took 
place  prior  to  ASARC/DSARC  I.  Most  existing 
techniques  for  conducting  Cost  and  Training 
Effectiveness  Analyses  (CPEA)  are  designed  for  use 
later  in  the  Weapon  System  Acquisition  Process 
when  more  specific  and  larger  amounts  of  design 
data  are  available.  The  present  analysis  over¬ 
came  this  lack  of  data  and  met  the  requirements 
for  conducting  preliminary  training  development 
studies  by  building  upon  the  comparabi 1 i ty 
analysis  techniques  and  data  base  embodied  in 
previous  applications  of  the  HARDMAN  methodology 
to  the  Division  Support  Weapon  System. 

The  previous  HARDMAN  training  requirements 
analysis  and  existing  consolidated  data  base 
facilitated  a  timely  study.  A  study  which  on 
the  average  takes  120  days t®) to  complete,  was 
completed  in  approximately  80  days. 

The  multidisciplinary  nature  of  the  HARDMAN 
approach  insured  that  the  overall  analysis  focused 
on  the  mission  requirements  of  the  weapon  system 
and  that  it  was  cohesive  and  comprehensive  in 
nature'.  This  multidisciplinary  team  of  hardware 
and  training  analysts  coupled  with  data  base 
management  techniques  and  analytic  models  was  able 
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to  br  idge  the  gap  between  the  needs  of  the  DARCOM 
developer  and  the  training  development 
community . 
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>  i  nger  -L  i  nk  and  the  Air  Force  Human  Resources  Laboratory  lAFriRL/,  a  i  l  I  i  jrr.s  Air  roro.- 
Base,  combined  efforts  to  investigate  spe-cifie  visual  requ  i  in  sri  ts  Juring  row- level,  f  i  gh- 
spoed  flight.  Visual  information  requirements  were  hypothec  i  z«  o ,  and  .r,  experiment 
designed  to  systematically  test  the  effects  of  various  visual  c  jes  upon  flight  per f or cun^- . 
The  experiment  tested  the  effects  of  visual  scene  elements  in  supporting  simulator  (light 
tasKS  of  experienced  Air  Force  fighter  pilots.  Specific  visual  rectors  stuoi-j  were:  ’.J  tn»- 
importance  of  surface  texture,  2.)  the  importance  of  3-J  objects  and  object  type,  anc  5.)  the 
effect  of  turning  and  bank  angle  upon  flight  per  form  jn^e .  pilot  subjects  were  eD  I  ♦-  to  con¬ 
trol  flight  at  a  mean  altitude  of  198  feet  and  at  an  airspeed  of  480  knots.  Test  esults 
indicate  that  both  3-D  objects  and  2-0  terrain  surface  texture  aid  control  Jv't  !  Ow-a  1 1  i  tube 
f  I  ight T 


INTRODUCTION 

Effective  air  defense  systems  require  tactical 
and  strategic  aircraft  to  fly  at  very  low  altitudes 
and  high  airspeeds.  These  altitudes  and  airspeeds 
enable  the  aircraft  and  crew  to  use  terrain  masking 
and  the  element  of  surprise  to  evade  hostile 
threats.  The  crew  of  today’s  tactical  and  stra¬ 
tegic  aircraft  must  balance  the  probability  of 
destruction  from  hostile  air  defense  systems  with 
the  probability  of  destruction  from  the  terrain,  r* 
segment  of  a  combat  mission  route  that  has  a  higs 
air  defense  threat  level  will  cause  the  aircrew  to 
fly  closer  to  the  terrain  and  to  accept  a  greater 
hazard  from  impact  with  the  ground. 

Experienced  pilots  have  little  difficulty  fly¬ 
ing  at  low  altitudes.  Unfor tunatel y ,  curing  a  com¬ 
bat  mission  the  pilot  must  also  navigate,  monitor 
the  aircraft  systems,  manage  the  weapon  systems, 
evade  the  hostile  threats,  and  perform  many  other 
critical  tasks*  The  pilot  must  practice  continu¬ 
ally  until  these  tasks  can  be  performed  almost 
automatical l y . 

The  amount  of  aircraft  I ow-d I t i tude ,  high¬ 
speed  flight  training  'i'.f-^sary  to  attain  this  per¬ 
formance  level  is  difficult  to  obtain  because  of 
cost,  safety,  noise,  and  pollution.  Simulators 
equipped  with  Computer  Image  Generation  (CIG) 
visual  systems  could  safely  provide  the  needed 
training  at  much  lower  cost  with  no  environmental 
impact.  The  potential  of  this  type  of  training  has 
been  demonstrated  and  the  savings  in  aircraft  and 
pilots  can  be  predicted  (5,  4).  However,  low- 
altitude,  high-speed  combat  mission  training  in 
simulators  is  not  presently  being  conducted  on  a 
large  scale. 

A  key  factor  inhibiting  the  large-scale 
development  of  Combat  Mission  Simulator  (CMS) 
facilities  is  visual  scene  content.  Present  termi¬ 
nology  is  not  adequate  to  describe  scenes,  and 
there  is  little  agreement  on  the*  relevant  ... har de¬ 


ter  istics  of  a  scene  (10).  In  addition,  data  con¬ 
cerning  scen«  content  requ  i  rei  icnts  is  scarce  (9). 

The  Low-Altitude  Database  Development  Evalua¬ 
tion  end  Research  (LADDER)  study  was  initiated  To 
examine  visual  scene  content  for  low-altitude, 
high-speed  flight  training,  and  to  gather  experi¬ 
mental  data  that  relates  experienced  pilot  perfor¬ 
mance  to  visual  scene  content.  To  obtain  this 
data,  a  generic  cockpit  trainer  equipped  with  a  CIO 
visual  system  was  developed,  ana  a  visual  database 
was  produced  to  manipulate  several  scene  content 
variables  throughout  a  high-speed,  low-altitude 
flight  route.  The  performance  of  experienced  mili¬ 
tary  pilots  was  recorded  during  simulated  flight 
and  subjected  to  statistical  analysis. 

APPARATUS 

A  special-purpose  research  simulator  was 
designed  and  assembled  at  the  Air  Force  Hufion 
Resources  Laboratory  (AFHRL).  The  simulator  con¬ 
sisted  of  a  modified  T-38  instrument  trainer  cock¬ 
pit,  a  modified  F-111  Computer  Image  Generation 
(CIG)  visual  system,  a  spec i a  I -pur pose  low-altitude 
database,  and  the  Advanced  Simulator  for  Pilot 
Training  (ASPT)  F-lb  flight  dynamics  and  perfor¬ 
mance  measurement  systems. 

Cockp i t 

The  coekp i t  was  part  of  a  surplus  T-?s  instru¬ 
ment  trainer.  Since  the  LADDER  study  was  concerned 
'nly  with  pilot  performance  relative  to  visual 
imagery,  only  the  airspeed  and  porcont-R-'M  instru¬ 
ments  wore  functional.  All  other  instruments 
within  the  cockpit  were  static  during  the*  exper  i  - 
men  t . 

T  he  T ,.untr  jl  stLr\  w  ;S  live.;  i  n  4  he  .  ■.  r.  t . 
position,  .jnJ  tr**  pilot’*  t^ntr.U  ■  r.p  its  w.  r  • 
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hybrid  of  the  F-1o  force  stU*\  cunrroi  kr  a nj  tr.-.- 
T-5d  Ltnf^r  J  i  sp  i  -jcenitrM r  0t  Uk.  Ue  i  UjT  v  .i  v. 
controlled  the  simulated  aircraft  Dy  varying  re.- 
force  app  I  i  ed  to  trie  nonmuv i ng  rjfieK.  the  T 
force  stick  inputs  were  direct*.  J  to  t he  AoPT  ^-lo 
flight  dynamics  simulation  progr  am .  The  program 
processed  the  control  inputs  and  genera  tea  Mis¬ 
appropriate  visual  System  eye-point  fliOv  efJle-n  *  to 
simulate  an  F-lb  aircraft  flight  path. 

V  i  sua I  System 

The  LADDER  visual  system,  consisted  of  a 
Singer-Link  F-111  Digital  Image  Generator  UIG)  and 
Wide-Angle  Collimated  (W«c>  displays. 

The  F-111  DIG  is  capable  of  generating  throe 
channels  of  day-dusk-night,  full-color  scenes, 
few  modifications  were  made  to  increase  its  scene 
generation  capacity.  Each  channel  presented  j  com¬ 
puted  scene  via  an  array  ot  3/b  by  10c 4  picture 
elements.  The  imagery  was  updated  at  a  r<jf*;  ot  5 j 
Hz. 

The  WAC  displays  consist  of  hi  gh-resol  ut  i  un 
color  monitors  matched  to  collimating  optics.  The 
displays  present  a  near- i  nf  i  n  i  ty  virtual  image*  ot 
the  computed  scene  to  the  pilot.  The  three 
displays  were  oriented  as  they  exist  in  the  F-111 
simulator:  to  the  left,  center,  and  right  of  the 
aircraft  centerline.  The  total  field  of  view  is 
approx imate I y  36  by  120  degrees. 

Low-A I t i tude  Database 

The  visual  system  database  was  specifically 
designed  to  evaluate  the  contribution  ot  different 
levels  of  scene  content.  The  basic  database  con¬ 
sisted  of  a  valley  corridor  3000  ft  wide,  which  was 
bordered  by  900-  to  11 00- ft  mountains.  Within  the 
valley  there  were  200-ft  transverse  level  and  slop¬ 
ing  ridges,  and  bOO-ft  hills.  The  corridor  permit¬ 
ted  pilots  to  fly  a  continuous  4 20— m i I e  route.  The 
corridor  construction  forced  pilots  to  continually 
change  their  altitude  and  heading  to  avoid  impact 
with  the  terrain. 

The  experimental  database  content  was  chosen 
for  its  anticipated  importance  to  the  low- 1  eve  I 
flight  task.  Previous  research  anu  experience  of 
Singer-Link  (b,  8),  and  HRL  (1,  2,  6,  7)  with  CIO 
database  features  indicated  that  some  features  were 
expected  to  have  a  significant  effect  upon  low- 
level  flight  performance.  Scene  content  features 
were  agreed  upon  by  Singer-Link  and  HRL. 

Visual  database  content  «as  studied  for  flight 
at  approx  iriiato  I  y  100- ft  AGL  and  a  true  airspeed  of 
4oJ  kt.  The  visual  factors  selected  were: 

1 . )  Importance  of  texture  and  texture  size.  Four 
texture  conditions  were  studied:  no  texture,  1  60- 
ft,  500-ft,  and  4b0-ft  square  texture  patterns. 
Texture  was  placed  only  on  the  floor  of  the  flight 
curr i dor . 

2. )  Importance  ot  5-D  objects  and  their  sizes  and 
shapes.  Five  object  conditions  were  studied:  no 
'-D  objects;  houses,  warehouses,  or  trees  alone; 
and  a  mixture  of  all  three  type’s  of  objects. 

5.)  yO-degree  sha  I  I  ow-tur  n  versus  1  80-degr  .**■ 
steep- turn  corridor  Sections.  Previous  research  at 
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E  i  gr»t  tit;  n  txpe  r i enc  e  d  tighter  pilots  with  low- 
love  I  flight  experience  par t i c i p  a  tod  in  the  experi¬ 
ment.  Ten  were  pilots  in  T-lo  training,  and  eight 
were  training  to  be  fighter  test  pilots.  The  mean 
age  of  the  pilots  was  34.o  years,  their  mean  total 
flignt  time  was  2,b13  hours,  and  their  mean  time  in 
f  i gh ter /  attack  aircraft  was  1 1>4 1  hours. 

Per  formanc€.‘  Measurement 

The  performance  sample  anu  measurement  capa¬ 
bility  of  the  Ai>PT  simulator  were  used  to  measure 
and  record  flight  path  parameters.  Performance 
parameters  during  flight  following  the-  practice 
period  were  Sampled  and  recorded  at  a  50-Hz  rat»-. 

At  a  prespecified  distance  in  each  segment,  r ecor a- 
i  rig  was  stopped  so  that  flight  performance  measure¬ 
ments  would  not  reflect  the  effect  of  visual  infor¬ 
mation  seen  uy  rhe  pilot  when  the  next  corridor 
segment  came  into  view. 

When  a  crash  occurred  during  flight  through  a 
segment,  that  condition  was  terminated.  The 
display  and  cockpit  were  initialized  to  the  begin¬ 
ning  of  the  subsequent  corridor  segment,  and  flight 
was  resumed . 

The  primary  flight  parameters  recorded  at  30 
Hz  included  position,  heading,  airspeed,  altitude, 
angle  of  attack,  angle  of  bank,  angle  of  pitch,  ana 
crash.  Many  other  parameters  were  also  recorded 
for  possible  use  in  analysis. 
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Exper imenta I  Procedure 

Each  pilot  flew  the  entire  corridor  with  the 
starting  condition  randomly  selected.  Pilots  were 
instructed  to  attempt  to  maintain  an  altitude  of 
100  ft  above  the  corridor  floor.  A  few  minutes  of 
practice  flight  were  given  to  each  subject,  ena¬ 
bling  him  to  accustom  himself  to  the  controls  and 
visual  system.  During  the  practice  flight,  alti¬ 
tude  and  airspeed  were  announced  verbally  to  the 
pilot  to  enable  him  to  visually  determine  an  alti¬ 
tude  of  100  ft  in  reference  to  the  corridor. 
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Comments  made  by  the  pilots  and  significant 
flight  events  were  noted  by  the  experimenter 
throughout  the  experiment.  Each  pilot  was  inter¬ 
viewed  following  the  data  collection. 

RL  SUL T  S 

Terrra i n  Crashes 

There  were  a  total  of  55  crashes  with  the  ter¬ 
rain.  The  distribution  of  crashes  among  the  corri¬ 
dor  segments  are  provided  in  Table  2;  'jtii  of  the 
crashes  occurred  in  steep-turn  sections  and  42% 
occurred  in  shallow-turn  sections.  Most  of  the 
crashes  (b1£)  occurred  in  sections  without  2-D  tex¬ 
ture  on  the  valley  floor.  The  rest  of  the  crashes 
were  distributed  throughout  the  remaining  sections 
with  2-D  texture . 

A  relatively  large  number  of  crashes  occurred 
in  two  separate  corridor  sections  that  had  2-D  tex¬ 
ture  and  5-U  objects  but  no  mountain  borders. 


*  Section  without  mountain  border 
TAdlE  2  -  NUMBER  U'F  TERRAIN  CRASHES 


Alii;  u'ie-  vOn  tv  j\ 

T  he  aver  age  a  I  t  i  t  aGe  t  tu:  pi  lots  ma  i  n  f  a  i  ned 
above  the  valley  f  I  our  (  i .e  . ,  altitude  above  f  I 
earth  only;  for  ail  conditions  was  1  ft.  Th* 
average  altitude  maintained  for  shallow- turn  5 
mc-nts  was  17b  ft,  -mo  /Vi  ft  for  bteep-tur  n  st-g 
men+s.  The  average  altitudes  maintained  for  ea 
condition  of  z-j  texture  and  ohje;  ts  are  l  1 

in  Table  S . 
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In  summary,  altitude  control  was  s  i  gn  i  t  i  an  1 1  Y 
wor  so  in  the  ste.-p-turn  st.-ctions;  the  Mixed  Object 

oonoitiun  was  t ho  best,  with  Trees  seLcn-i-buS t  and 

* io  j  0  j  e  _  t  s  woi  st ,  T  here  * •  jS  no  r  e  I  i  a  b  >  o  m o  i  n 
•  -ffect  of  Icxfurt:  on  altitude  control,  but  rhcr  •.* 
wjs  a  reliable  interaction  between  objects  and  to*- 
t-jre  Such  that  trie  combination  ut  50u-  f  t  square 
pattern  with  Mixed  objects  was  the  best  condition. 
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TABLE  3  -  MEAN  ALTITUDE  (feet; 

if#***##******#*###****#***#*#**#*#*# 

The  dependent  variables  of  RMS  error  altitude, 
maximum  altitude,  ana  mean  altitude  above  flat 
earth  were  included  in  a  multivariate  analysis  (the 
SPSS  MANOVA  Procedure  Release  9.0)  to  include 
univariate  F-tests.  An  alpha  level  of  0.10  was 
chosen  for  the  univariate  tests.  Scheffe's  S- 
method  was  used  to  explicate  the  F-test  results. 

The  main  effects  of  turn  and  object  factors  were 
significant  on  at  least  two  of  the  three  dependent 
measures.  The  F-tests  on  the  interaction  effects 
of  Objects  X  Texture  was  significant.  In  addition, 
all  subject  effects  were  significant. 


Pijot  Reports 

The  pilots'  Subjective  comments  concerning  tne 
effectiveness  of  the  various  combinations  of  scent? 
content  indicated  trial  must  of  the  test  „ori0  i  t  ions 
were  able  to  support  low-altitude  480-kt  flight. 

Trie  comments  contained  no  consistent  preference  tor 
either  texture  size  or  object  type.  Many  pilots 
commented  that  they  had  no  idea  of  how  high  or  low 
they  were  in  the  No  Object  or  No  Texture  condition. 
The  pilots'  levels  of  comfort  and  confidence  with 
the  scenes  increased  as  features  were  added  to  the 
corridor  segments.  The  ranking  from  low  to  high 
resulting  from  additional  corridor  content  was  3-D 
objects,  2-U  surface  texture,  ana  both  3-D  uno  2-D 
f eatures . 


It  should  be  noted  at  the  outset  that  the  data 
contain  a  high  level  of  between-  and  wi th i n-sub jecf 
variability,  and  that  the  variance  is  not  always 
distributed  heterogenous  I y .  The  task  structure 
allowed  differences  in  individual  flying  technique, 
particularly  in  terms  of  lateral  flight  path  (i.e., 
the  pilot  chose  his  path  within  the  3,000-ft  wide 
corridor).  For  example,  some  oilots  worked  very 
hard  to  avoid  going  over  the  portions  of  elevated 
terrain,  whereas  other  pilots  attempted  to  fly  the 
shortest  distances  regardless  of  terrain.  In  addi¬ 
tion,  many  pilots  attempted  different  strategies 
during  the  course.  Much  of  this  type  of  variabil¬ 
ity  cannot  be  controlled  with  group-or i ented  sta¬ 
tistical  analyses.  The  nature  of  the  variability 
may  have  concealed  some  effects  that  may  be 
revealed  in  a  more  structured  task.  The  data  col¬ 
lection  procedure  used  in  this  study  did  not  lend 
itself  to  idiographic  analysis  techniques. 

The  steep-turn  corridor  section  was  clearly 
associated  with  poorer  altitude  control  than  the 
shallow-turn  segment,  presumably  because  of  the 
difficulty  of  the  greater  bank  angles  required  in 
the  steep-turn  section. 

Tne  main  effect  of  texture  was  not  reliable  (p 
=  .069).  There  were  reliable  effects  of  Object 
type  on  both  RMS  error  (p  =  .056)  and  maximum  alti¬ 
tude  (p  =  .06).  Post  hoc  tests  (Scheffe’s  S- 
rnethod)  revealed  that  for  RMS  error,  the  Mixed 
Object  condition  was  significantly  better  than 
either  the  No  Object  or  Houses  Only  condition.  On 
the  maximum  altitude  variable,  the  Mixed  Object 
condition  was  reliably  better  than  the  No  Object, 
Houses,  and  Warehouse  conditions.  Additionally, 
the  Trees  were  associated  with  significantly  lower 
maximum  values  than  Houses,  Warehouse,  or  No 
Object.  Warehouses  were  reliably  better  than  No 
Objects . 


Experienced  pilots  felt  they  could  follow  the 
terrain  at  low  altitudes  in  the  LADDER  database. 
After  completing  the  experiment,  which  lasted  over 
an  hour,  many  pilots  requested  more  simulator  time 
to  test  their  flight  control  capabilities  beyond 
the  task  of  maintaining  an  altitude  of  100  ft. 
During  these  unrecorded  sessions,  pilots  con¬ 
sistently  flew  at  altitudes  as  low  as  30  ft  without 
zr ash i ng  . 


DISCUSSION 

Considering  the  results  of  the  terrain  crash 
and  altitude  data  along  with  pilot  opinion,  if  is 
clear  that  a  combination  of  3-D  objects  and  2-D 
terrain  surface  texture  best  supports  controlled 
low-altitude  flight.  The  distribution  of  terrain 
crashes  most  clearly  reflects  the  importance  of 
both  types  of  cues.  The  results  of  previous 
research  had  led  us  to  expect  a  more  systematic 
relationship  of  performance  with  respect  to  the 
size  of  surface  texture  squares.  The  present  study 
die  not  reveal  a  reliable  main  effect  of  surface 
texture.  The  ordinal  rankings  suggest  that  the 
300-ft  square  condition  was  the  most  effective  and 
the  No  Texture  condition  the  least  effective.  It 
is  curious  that  the  clear  inferiority  of  the  No 
Texture  condition  as  reported  by  the  pilots  and 
reflected  in  the  distribution  of  terrain  crashes 
was  not  reflected  in  at  least  the  RMS  error  meas¬ 
ure.  However,  note  that  the  visual  database 
included  model i ng  the  effects  of  sun  angle  so  that 
shading  cues  were  almost  always  present  to  signal 
variations  in  terrain,  and  that  the  bordering  moun¬ 
tains  provided  strong  peripheral  cues  to  changes  in 
altitude.  This  suggests  that  even  the  most  impo¬ 
verished  cue  conditions  contained  sufficient  intor- 
mjtion  about  jurf.u.e  orient  jtiun  tor  some  altitude* 
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control . 

Another  somewhat  surprising  finding  is  the 
effectiveness  of  the  Mixed  Object  condition.  The 
results  of  previous  research  had  indicated  the 
potential  tor  abstract  geometric  shapes  (pyramids 
and  cones)  to  aid  in  altitude  control  and  terrain 
avoidance.  However,  the  Mixed  Object  condition  did 
not  differ  significantly  from  the  Tree  condition  on 
the  Maximum  altitude  variable,  and  both  were  supe¬ 
rior  to  the  two  building  types  and  to  no  objects  at 
all.  On  the  RMS  error  measure  only,  the  Mixed 
Object  condition  was  found  to  be  reliably  superior 
to  the  Houses  or  No  Object  condition.  It  is  possi¬ 
ble  that  the  differences  in  size  and/or  shape  of 
the  objects  when  found  together  in  a  section  pro¬ 
vided  a  significant  enhancement  of  information  that 
the  pilot  cou I d  use. 
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A  much  greater  difference  in  performance 
attributable  to  objects  and  texture  was  desired. 
Even  the  results  found  to  be  statistically  reliable 
were  not  large  in  terms  of  absolute  magnitude  (with 
the  exception  of  the  differences  between  steep  ana 
shallow  turn).  As  noted  earlier,  problems  with 
performance  variability  due  to  the  task  structure 
and  differences  in  individual  technique  may  have 
concealed  some  perceptual  relationships.  However, 
it  is  equally  plausible  that  since  the  pilots  did 
not  have  to  simultaneously  attend  to  navigation  or 
tactical  tasks,  the  visual  environment  provided 
sufficient  information  in  even  the  No  Object  or  No 
Texture  condition  to  maintain  relatively  good  low- 
level  performance.  The  minimum  scene  content  con¬ 
dition  of  a  corridor  with  mountains,  ridges,  and 
hills  (and  sun  shading)  may  have  been  nearly  ade¬ 
quate  for  the  pilots  to  maintain  low-altitude 
flight.  The  relatively  large  number  of  crashes  in 
the  two  segments  without  the  bordering  mountains 
suggests  this  might  be  true.  The  corridor  without 
texture  or  objects  in  the  valley  is  still  more  com¬ 
plex  than  most  training  simulator  databases  avail¬ 
able  today.  The  perceptual  problem  facing  the 
pilots  was  also  somewhat  easy,  since  the  valley 
floor  was  always  flat  and  level,  except  for  the 
obvious  ridges  and  hills.  This  allowed  pilots  to 
make  the  valid  perceptual  assumptions  that  reduced 
their  need  for  additional  visual  information  to 
resolve  ambiguities. 

The  pilots  who  participated  in  the  experiment 
demonstrated  that  CIG  scenes  can  support  low- 
altitude,  high-speed  flight  control.  During  the 
experiment,  the  pilots  maintained  an  overall 

average  altitude  of  I 9tJ  ft,  which  is  higher  than 
the  100  ft  above  the  valley  floor  that  the  pilots 
were  instructed  to  majntain.  This  result  should  be 
expected,  since  the  200-ft  ridges  within  the  corri¬ 
dor  occasionally  forced  the  pilots  to  fly  higher 
than  100  ft.  In  addition,  most  of  the  pilots  con¬ 
trolled  their  altitude  to  fly  no  lower  than  100  ft 
instead  of  maintaining  an  average  altitude  of  100 
ft.  These  two  factors  would  cause  the  average 
altitude  to  be  greater  than  100  ft. 

The  LADDER  experimenf  required  the  pilots  to 
fly  the  corridor  at  low  altitude  for  approximately 
one  hour.  Since  pilots  in  the  past  have  otter, 
expressed  a  distaste  for  flying  simulators,  it  was 
surprising  that  many  pilots  requested  more  time  to 
exercise  both  man  and  simulator  to  the  limits  of 
performance.  Their  requests  and  the  extremely  low 
flight  maneuvers  they  accomplished  during  these 
periods  attest  to  the  effect  ivenc-s  of  the  scene 


...on  tent  in  most  of  the  LAUDED  database  corridor 
v  .  t  i  cns . 

The  issue  of  ‘jU-nu  content  is  f a  r  from  being 
i  cSvl  vyj.  However  ,  the  LADDER  database  has  a trrnw-n— 
Strafed  that  it  is  possible  to  produce  a  Li  0  data¬ 
base  thdt  supports  iow-dl t i tude,  high-speed  flight 
In  this  sense,  the  results  of  the  experiment  are 
very  encouraging.  Clearly,  more  basic  and  applied 
research  is  needed  to  better  understand  the  rela¬ 
tionship  between  pilot  per  forinance  and  visual  Sys¬ 
tem  database  content. 
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The  current  trend  In  user  requirements  for  data  bases  to  support  visual,  sensor,  and 
rada1'  simulation  for  training  Ls  toward  real-world  data  bases  that  cover  large  geographic 
area?.  The  production  of  these  data  bases  ls  an  expensive  process  and  typical  lv  each  new 
system  develops  new  data  base  generation  software,  along  with  a  data  base  Itself,  to  meet  Its 
own  specific  needs.  The  result  Is  a  large  amount  of  redundant  effort,  since  the  same 
geographic  area  may  be  modelled  or  transformed  repeatedly  for  different  applications.  This 
paper  will  describe  an  approach  to  help  the  Department  of  Defense  (DoD)  control  the  encali  t  in 
costs  of  generating  and  maintaining  simulator  digital  data  bases.  This  approach  will  he 

developed  through  Air  Force  Project  2851,  Common  DoD  Simulator  Digital  Data  Base /Trans¬ 
formation  Program,  a  trl-servlce  effort  which  was  Initiated  at  the  direction  of  the  Joint 
Logistics  Commanders  (JLC)  DoD  Joint  Technical  Coordinating  Group  on  Simulators  and  Training 
Devices  (JTCG-STD) 

The  objective  of  Project  2851  Is  to  develop  a  DoD  standard  simulator  data  base  and  common 
transformation  software  to  support  al L  simulator  training  devices  requiring  the  use  of  digital 
topographic  data.  The  DoD  standard  simulator  data  base  will  provide  a  common  source  of  digital 
data  that  will  be  specifically  compiled  to  meet  training  objectives  and  which  will  minimize  the 
need  to  enhance  Defense  Mapping  Agency  (DMA)  data  during  the  data  base 
generat Ion/ trans format  Ion  process  for  each  Individual  simulator  system.  The  goal  of  the  common 
transformation  program  is  to  reduce  the  amount  of  system  unique  software  for  each  simulator 
system.  It  will  promote  a  greater  degree  of  data  base  and  software  compatibility  among  the 
many  DoD  simulator  systems.  The  results  of  the  project  should  be  Improved  simulator  training 
capability  at  reduced  development,  acquisition,  and  life  cycle  cost  to  the  Government, 


INTRODUCTION 

Project  2851  -  Common  Simulator  Digital  Data 
Base/Trans  format  Ion  Program  -  is  a  trl-servlce 
simulator  software  applications  and  data  base 
development  program  assigned  to  the  Aeronautical 
Systems  Division  (ASD)  of  the  Air  Force  Systems 
Command  (AFSC)  by  the  Department  of  Defense  (DoD) 
Joint  Logistics  Commanders.  The  purpose  of  the 
project  Is  to  develop  a  standard  simulator 
topographic  data  base  and  to  minimize  the  number 
of  data  base  transformation  programs  for  various 
DoD  training  simulators.  The  term  "simulator  data 
base"  in  this  paper  refers  to  a  topographic  data 
base  containing  a  description  of  terrain  relief, 
and  natural  and  man-made  features  on  the  surface 
described  by  the  terrain.  It  may  contain  car¬ 
tographic,  hydrographic  and/or  topographic 
features.  This  paper  describes  the  background  and 
problems  associated  with  the  current  procedures 
for  generating  simulator  digital  data  bases  for 
training  simulator  applications,  the  major 
requirements  that  wllL  he  addressed  by  Project 
2851,  the  program  approach  to  be  taken  and  related 
technical  support. 

BACKGROUND 

Topographic  data  bases  are  required  whenever 
the  simulation  involves  a  visual  or  sensor  capabi¬ 
lity.  Visual  systems  are  required  for  training 
tasks  such  as  take-off  and  landing  for  aircraft, 
harbor  navigation  for  ships,  and  artillery  prac¬ 
tice  for  tanks.  Sensor  simulation  systems  are 
required  for  training  tasks  Involving  radar  or 
electro-optical  systems  such  as  Infrared  sensors 
or  low  light  level  television.  The  data  base  pro¬ 


vides  the  model  from  which  the  simulated  Image  Is 
generated.  Data  bases  used  In  the  past  have 
Included  model  hoards  built  on  either  a  stationary 
platform  or  on  a  moving  belt  for  visual  and  opti¬ 
cal  glass  plate  transparencies  for  radar.  How¬ 
ever,  the  last  ten  years  have  seen  a  shift  to 
computer  based  simulation  systems  using  a  digital 
topographic  data  base.  Computer  Image  generation 
(CIG)  systems  and  digital  radar  landmass  simulator 
(DRLMS)  systems  now  permit  real L Stic  vLsual  and 
radar  simulation  of  real  world  areas  over  large 
geographic  expanses. * 

In  an  attempt  to  standardize  cartographic  and 
geodetic  data  base  support  throughout  the  DoD,  the 
Defense  Mapping  Agency  (DMA)  was  formed.  The 
first  prototype  digital  data  base  was  developed  hv 
DMA  in  1974,2  primarily  in  support  of  radar 
simulation  requirements.  However,  since  that 
time,  DMA  data  base  applications  have  expanded  to 
Include  tactical  and  strategic  weapon  systems.  In 
1977,  a  major  revision  to  the  DMA  data  base  was 
accomplished  to  Improve  the  detail  and  descriptive 
content.  The  1977  data  base,  referred  to  as  First 
Edition  Digital  Landmass  System  (DLMS)  data"', 
includes  two  f  l  les-ter ra l n  elevation  and  feature 
analysis.  The  terrain  elevation  file  consists  of 
a  3  arc-second  by  3  arc-second  matrix  of  elevation 
values  which  represent  the  elevation  of  the 
earth’s  surface.  The  feature  anal  vs  Is  file  is  the 
more  complex  of  the  two  and  contains  a  description 
of  all  features  on  the  earth's  surface,  both 
natural  (Lakes,  rivers,  forests,  fields)  and 
manmade  (buildings,  roads,  towers,  bridges). 
Descriptions  within  the  feature  analysis  file 
Include  geographic  location,  feature  Iden¬ 
tification  (truss  bridge,  two  lane  highway,  res  l- 
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deni  Lai  bulLding,  etc.),  surface  material  category 
(metaL,  wood,  soLL,  water,  etc.),  feature  height, 
percent  tree  cover,  and  percent  roof  cover. 

Use  of  the  DMA  DLMS  is  now  required  as  the 
prLmary  source  of  information  for  all  DoD  simula¬ 
tor  data  bases.  The  basic  feature  content, 
accuracy,  and  resolution  of  the  DLMS  data  have 
proved  adequate  for  the  simulation  of  low  to 
medium  resolution  radar  systems.  The  DLMS  data 
has  also  proved  useful  for  visual  and  sensor  simu¬ 
lation  applications  provided  certain  enhancements 
are  added. 

DATA  BASK  PROBLEMS  TO  BE  SOLVED 
Data  Base  Transformation  Programs 

As  described  in  the  previous  section,  the  DLMS 
data  is  defined  Ln  terms  of  ground  truth  physical 
descriptors  and  is  Ln  a  DMA  standard  format.  CIO 
and  DRLMS  systems,  however,  require  that  the  data 
base  be  in  a  format  compatible  with  the  particular 
system  archi tecture.  They  also  require  certain 
descriptors  In  addition  to  those  Included  in  the 
DMA  data  for  visual  displays  (coLor,  texture 
patterns),  and  radar  displays  (feature  reflectance 
codes).  In  order  to  convert  from  the  DMA  data 
base  to  one  compatible  with  the  specific  simulator 
system,  a  conversion  program,  commonly  referred  to 
as  a  data  base  transformation  program,  must  be 
developed.  In  the  case  of  a  visual  data  base?, 
manual  enhancement  using  additional  data  sources 
Is  usually  required  to  supplement  the  trans¬ 
formation  process.  The  transformation  program 
development  (and  enhancement  process  for  visual 
systems)  Is  performed  by  the  simulator  contractor 
for  each  new  simulator  system.  Figure  1  illustra¬ 
tes  the  transformation  process  for  both  radar  and 
visual  systems. 


Unique  transformation  programs  are  required 
for  each  simulator  system  for  several  reasons. 
Due  to  the  complexity  of  visual  system  design, 
only  a  limited  number  of  edges  or  polygons  can  be 
used  to  represent  a  given  scene  (typically  on  the 
order  of  4000  to  ROOD  edges).  Therefore,  visual 
system  data  base  content  must  be  restricted  to 
those  features  necessary  to  meet  the  specific 
training  task.  For  example,  a  visual  data  base 
used  for  low  level  navigation  might  require  empha¬ 
sis  on  roads,  streams,  vegetation  patterns,  and 
predominant  terrain.  On  the  other  hand,  a  data 
base  used  for  air-to-ground  weapon  delivery  might 
require  more  emphasis  on  specific  cultural  objects 


or  surface  vehicles.  The  t  runs  f  n  rma  t  l  on  program 
must  therefore  he  designed  to  select  those 
features  of  Importance  and  use  them  to  produce  a 
visual  data  base  compatible  with  the  visual  svstem 
a rch i tecture.  Similarly,  the  radar  data  base 
transformation  progr  im  must  perform  the  same  func- 
t  Ion  to  produce  a  data  base  compatible  with  the 
radar  system  arch  i  t  ect  tire .  Since  each  system  lias 
its  own  format  and  content  requirements  and  there¬ 
fore  requires  its  own  transformation  capability, 
a  transformed  radar  data  hase  is  not  compatible 
with  a  visual  system,  nor  can  a  radar  system  use  a 
transformed  visual  data  hase.  In  fact,  a  visual 
system  can  seldom  use  a  data  base  from  a  different 
visual  system  due  to  differing  system  capacities 
or  capabilities  and  unique  system  or  contractor 
designs.  The  same  problem  exists  In  the  radar  md 
sensor  areas. 

There  are  several  consequences  to  the  current 
practice  of  transformation  program  acquisition. 
The  first  Ls  the  large  recurring  cost  of  software 
development  for  every  new  simulator  program 
involving  a  visual,  radar,  or  sensor  requirement. 
Visual  transformation  programs,  typically  75,000 
to  150,000  lines  of  code,  are  a  significant  part 
of  the  software  development  process.  Second,  the 
growth  in  the  number  of  transformation  programs 
places  a  burden  on  simulator  computer  facilities. 
Third,  maintaining  this  proliferation  of  the 
transformation  programs  and  keeping  them  current 
with  the  DMA  data  base  Is  and  will  continue  to  be 
a  problem.  Finally,  the  effort  to  create  data 
bases  becomes  highly  redundant.  This  Is  espe¬ 
cial  ly  true  for  a  simulator  with  visual  ,  radar, 
and  sensor  simulation  systems,  each  with  data  base 
requirements  covering  the  same  geographic  area, 
but  in  a  different  format. 

As  a  result  of  the  Initial  concept  development 
of  the  data  hase  transformation  process  and  the 
development  of  several  operational  simulators,  It 
has  become  evident  that  some  additional  control  of 
this  process  ls  needed.  It  Is  highly  deslreable 
to  reduce  the  redundant  and  complex,  time  con¬ 
suming  transformations  and  enhancements. 

Simulator  Data  Base  Adequacy 

As  previously  explained,  DLMS  data  has  been 
adequate  for  some  recent  simulator  acquisition 
programs,  while  It  has  required  major  enhancement 
for  others.  However,  current  DLMS  data  does  not 
appear  suitable  for  future  simulator  programs 
Involving  high  resolution  radar  and  sensors,  or 
visual  systems  requiring  large  geographic  areas. 
There  are  three  reasons  for  this. 

First,  the  resolution  and  content  of  the  DLMS 
data  hase  Is  not  adequate  for  the  simulation  of 
new  sensor  systems  such  as  synthetic  aperture 
radar  (SAR),  which  Is  capable  of  ten  foot  range 
and  azimuth  resolution.  The  current  DMA  DLMS  data 
Is  not  a  one-for-one  representation  of  features  on 
the  earth's  surface.  To  be  Included  In  the  DLMS 
data  base,  a  feature  must  meet  a  set  of  criteria 
with  regard  to  tvpe,  material,  minimum  sire,  anti 
minimum  adjacent  feature  separation,  tvplcullv  on 
the  order  of  j DO  to  SnO  feet;  thus  certain 
features  mav  not  be  port  raved  at  al  1  or  mav  be 
included  as  part  of  a  homogenous  grouping  of  simi¬ 
lar  objects.  For  example,  a  large  feature  mav 
represent  a  combination  of  Individual  structures 


e.g.,  residential  plat,  factory  complex,  commer¬ 
cial  buildings.  In  some  cases,  a  small  town  mnv 
consist  of  only  one,  two  or  three  features.  On 
the  other  hand  tvpieal  high  resolution  sensor 
systems  are  capable  of  displaying  a  one  for  one 
representation  of  Individual  buildings  and 
Landscape  features.  Therefore,  a  significant 
amount  of  additional  detail  would  need  to  he  added 
to  the  current  DLMS  data  before  it  would  meet  the 
requirements  for  high  resolution  simulation  appll- 
cat ions . 

The  second  data  base  problem  deals  with  the 
lack  of  necessary  feature  descriptors.  The  DMA 
DLMS  data  was  originally  defined  In  support  of 
radar  simulation;  as  such,  information  unique  to 
visual  or  sensor  simulation  applications  such  as 
color,  surface  patterns  (runway  stripes),  and 
detailed  three  dimensional  information  are  not 
contained  within  the  data  base.  For  current 
applications,  the  DLMS  data  requires  enhancement 
which  is  usually  accomplished  manually.  Although 
this  approach  may  produce  acceptable  results  over 
limited  geographic  areas,  a  high  level  enhancement 
is  not  practical  for  extended  gaming  areas  that 
cover  hundreds  or  thousands  of  square  nautLcal 
ml  les . 

The  third  data  base  problem  Is  that  of  availa¬ 
bility  for  specific  geographic  areas  of  interest. 
For  any  data  base  product  requirement,  DMA  produ¬ 
ces  data  for  a  specific  area  of  geographic 
coverage  based  upon  available  allocated  resources 
and  assigned  project  priority.  Therefore,  a  new 
simulator  project  or  one  with  a  low  priority  may 
have  a  difficult  time  obtaining  the  desired  area 
of  coverage  unless  that  area  coincides  with 
existing  data  base  production  efforts.  The  compe¬ 
titive  environment  for  obtaining  DMA  support 
includes  not  only  simulator  programs  from  all 
three  services,  but  also  strategic  and  tactical 
weapon  system  applications  such  as  missile 
guidance  systems,  aircraft  cockpit  map  displays, 
and  aircraft  navigation  aids. 

PROJECT  2851  OBJECTIVES  AND  REQUIREMENTS 
Object  Ives 

The  problems  described  in  the  previous  section 
were  recent Ly  acknowledged  by  the  Joint  Logistics 
Commander’s  Joint  Technical  Coordinating  Group  on 
Simulators  and  Training  Devices  (JTCG-STD).  As  a 
result,  Ln  early  1982  the  JTCG-STD  named  AFSC  as 
the  lead  organization  in  a  trl-servlce  effort  to 
develop  a  standard  DoD  simulator  data  base  and 
common  simulator  transformation  software.  The 
program  was  designated  Project  2851  under  Air 
Force  Program  Element  64227F.  One  of  the  initial 
steps  was  to  establish  a  working  group  consisting 
of  ASD,  Naval  Training  Equipment  Center  (NTKC)  and 
Army  Program  Manager  for  Training  Devices 
(PM-TRADE).  The  Defense  Mapping  Agency  also  ser¬ 
ves  as  a  supporting  organization.  Although 
funding  began  In  FY84  ,  the  Initial  planning  and 
some  detailed  In-house  efforts  started  earlier. 
Project  2851  will  address  simulator  data  base 
requirements  in  the  following  three  primary  areas. 

Technical  Requirements. 

The  data  base  transformation  software  and 
standard  simulator  data  base  must  he  compatible 


with  the  technical  requirements  for  .  *  1  i  tvpes  of 
future  training  systems.  This  will  Include 
visual,  high  resolution  radar  such  as  SAR ,  and 
high  resolution  electro-optical  systems  such  as 
Infrared  and  low  light  level  television.  In  addi¬ 
tion,  the  training  systems  associated  with  each  of 
the  three  services  must  also  be  considered  i.e., 
air,  ground,  and  naval  simulation  systems.  The 
new  data  base  structure  and  content ,  and  the 
transformation  software  must  he  compatible  with 
the  basic  architecture  and  data  base  processing 
capability  of  current  state-of-the-art  simulation 
devices,  and  must  also  be  flexible  to  permit 
changes  as  simulation  technology  evolves. 

Operational  Requirements. 

The  standard  simulator  data  base  must  meet  the 
operational  training  needs  of  a  wide  variety  of 
different  requirements  associated  with  Army,  Navy, 
and  Air  Force  simulator  applications.  Both  car¬ 
tographic  and  hvdrographlc  data  will  need  to  he 
considered.  The  varied  types  of  training  pLace 
different  kinds  of  requirements  on  the  data  base. 
These  requirements  range  from  very  large  areas 
(one  million  square  nautical  miles)  with  low  to 
moderate  detail  to  limited  areas  (hundreds  of 
square  nautical  miles)  with  very  high  detail  to 
some  combination  of  these  extremes.  There  are 
also  requirements  to  support  initial  training, 
transition  training,  and  continuation  training, 
including  mission  rehearsal.  Individual  programs 
must  he  able  to  select  and  implement  only  what 
they  need  from  the  standard  data  hase.  Individual 
site  updates  or  modifications  will  still  be 
necessary  In  order  to  support  Individual  mission 
needs,  but  these  changes  can  he  fed  hack  to  the 
central  data  hase  site  so  that  aL 1  users  can  bene¬ 
fit. 

The  most  significant  data  hase  requirements 
that  need  to  be  supported  are  world  wide  area  of 
coverage  and  mission  rehearsal.  Mission  rehearsal 
in  particular  will  be  a  significant  challenge 
since  a  ground  truth,  feature  by  feature  repre¬ 
sentation  of  the  earth’s  surface  may  he  required 
for  many  simulator  applications.  Another  major 
challenge  will  he  the  development  and  merging  of 
highly  detaLled  areas  of  real  and  synthetic  data. 
The  standard  simulator  data  hase  must  support 
enhancement  of  DLMS  data,  Including  manuaL  enhan¬ 
cement,  insertion  of  generic  feature  models,  and 
addition  of  non-real  world  information  using  a 
process  called  synthetic  breakup.14 

Support  Requirements. 

Once  a  standard  data  hase  is  created  to  meet 
the  operational  requirements,  the  need  will  exist 
to  generate  on-line  simulator  data  bases  I.e., 
develop  data  hase  transformation  programs  maintain 
configuration  control,  and  update  the  data  hases 
when  new  source  information  becomes  available. 
Configuration  management  will  he  particularly 
important  to  insure  data  hase  availability  for  all 
simulator  users  and  to  avoid  duplication  of  data 
base  generation  effort.  Once  a  data  hase  is 
generated  for  a  particular  geographic  area, 
information  on  its  availability,  content  and 
currency  must  be  accessible  to  all  simulator 
users . 
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center  will  be  needed  to  provide  support  for 
operational  simulators  and  acquisition  programs. 
Data  bases  for  new  areas  will  be  generated  and/or 
transformed  In  support  of  users  and  for  test  and 
deployment  of  new  simulators.  The  magnitude  of 
this  task  will  vary  continuously,  depending  on  the 
numbers,  types  and  sizes  of  areas  needed.  This 
center  will  have  to  modify  and/or  update  previ¬ 
ously  generated  areas  based  on  revised  source  data 
and  Inputs  from  the  field.  There  will  he  i  con¬ 
tinuing  need  to  work  with  users  and  contractors 
developing  new  simulators  to  rapidly  analyze  and 
resolve  problems  as  they  arise.  The  center  must 
support  the  test  and  evaluation  activities  of 
acquisition  programs  by  supplying  data,  trans¬ 
forming  data  and  resolving  discrepancies  In  test 
results.  Provisions  for  continuing  research  and 
development  activities  must  he  Included  to  take 
advantage  of  new  data  base  source  materials  and  to 
maintain  compatibility  with  new  Image  generation 
techniques  and  transformation  schemes.  Finally  It 
will  be  extremely  Important  to  keep  the  data  base 
documentation  current  so  that  the  data  base  con¬ 
tent  for  any  desired  geographic  area  can  Imme¬ 
diately  be  determined. 

PROJECT  28 81  APPROACH 

The  data  base  generat  lon/transformat  Ion 
process  envisioned  Is  Illustrated  In  Figure  2. 
All  applicable  sources  of  topographic  data  will  be 
utilized  and  converted  to  a  common  datum.  The 
simulator  data  base  will  be  generated  by  digi¬ 
tizing  these  cartographic,  hydrographic,  and  pho- 
togrammetrlc  sources  and  merging  them  with  OEMS 
data.  Generic  models  and  synthetic  data  may  also 
be  used  to  enhance  the  OEMS.  The  final  product  of 
this  process  will  be  a  standard  simulator  digital 
topographic  data  base.  Provisions  for  updating 


this  data  base  will  be  provided.  At  this  stage 
the  standard  simulator  data  base  shown  In  Figure  2 
Is  not  yet  In  a  form  ready  to  be  directly  loaded 
In  a  simulator.  Because  of  the  complexities  of 
some  of  the  transformation  processes  and  the  very 
lengthy  time  required  for  transformation,  a  goal 
has  been  established  to  Identify  the  common  trans¬ 
formation  tasks  and  perform  them  once  for  all 
applications.  it  may  be  necessary  to  have  Indivi¬ 
dual  trans  format  Ion  programs  for  a  limited  number 
of  classes  of  applications  e.g.  ,  conventional 
radar,  synthetic  aperture  radar,  CIG  Type  A,  GIG 
Type  B,  etc.  Ideally,  transformed  data  bases  will 
be  In  a  format  nearly  ready  for  use  by  a  par¬ 
ticular  simulator.  In  order  to  exactly  match  this 
transformed  data  base  to  a  particular  Image 
generator,  an  adapt  at  Ion/ format t Ing  program  will 
be  required  for  each  simulator  application.  The 
goal  Is  to  maximize  the  common  transformation  pro¬ 
cessing  and  minimize  the  tasks  remaining  for  the 
adaptat Ion/ format!  Ing  program.  The  feasibility 
and  practicality  of  this  approach  remains  a  sub¬ 
ject  for  further  study. 

This  data  hase  generat  Ion/ trans  format  Ion  pro¬ 
cess-  Is  flexible  enough  to  satisfy  multiple 
purpcccs  and  many  types  of  requirements.  It  per¬ 
mits  a  specific  program  to  extract  what  Is  needed 
to  satisfy  Its  specific  requirements.  There  are 
provisions  for  higher  resolution  data  developed 
by  a  specific  program  to  he  added  to  the  standard 
simulator  data  base  and  be  available  for  sub¬ 
sequent  users.  Synthetic  or  non  real  world  enhan¬ 
cements  can  be  documented  and  separated  from  real 
world  data.  This  scheme  provides  needed  flexibi¬ 
lity  for  Individual  programs  but  also  forces  Indi¬ 
vidual  data  bases  to  he  portable,  thus  reducing 
redundant  modeling  and  generation  efforts.  Bv 
maintaining  the  standard  simulator  data  hase  In  a 


partially  transformed  form,  the  complex,  time  con¬ 
suming  trans format  Ion  processing  can  he  reduced 
for  each  application.  It  Ls  essential  that  the 
partially  transformed  data  base  he  independent  of 
any  particular  Image  generator  design  yet  contain 
aLl  Information  that  might  he  utilized  for  a  par¬ 
ticular  application.  This  approach  does  Involve 
knowledge  of  simulator  subsystem  design  to  some 
extent,  but  this  Is  a  reasonable  tradeoff  con¬ 
sidering  the  benefits.  If  there  Is  a  significant 
advancement  In  the  state-of-the-art,  the  Initial 
(common)  t rans format  Ion  process  can  be  modified  to 
raaintaLn  compatibility  with  newer  simulator  sub¬ 
system  designs. 

The  lmplementat Ion  plan  for  Project  2RSL  will 
employ  a  combination  of  in-house  Government 
resources  and  contracts  with  Lndustry.  By  util¬ 
izing  this  combined  expertise,  an  optimized  solu¬ 
tion  to  the  data  base/ trans f ormat ion  problems  can 
be  attained.  The  Government  has  knowledge  of  the 
requirements  and  problems  experienced  with  past 
simulator  systems  developed  by  several  manufac¬ 
turers  and  the  objectivity  to  keep  the  solution 
generic  and  not  favor  any  one  design  approach. 
Industry  has  knowledge  of  simulator  subsystem 
design  and  first  hand  experience  with  simulator 
data  base  design  and  development.  The  following 
six  tasks  describe  the  development  strategy  to  be 
fol Lowed.  A  schedule  Is  provided  in  Figure  3. 

Task  1  -  Data  Collection  and  Technology  Baseline 

Def Ini t Ion. 

A  comprehensive  list  of  existing  and  planned 
DoD  training  simulators  that  require  the  use  of 
digital  topographic  data  for  visual,  sensor  and 
radar  image  generation  will  be  developed.  For 
each  simulator  system,  the  data  base  requirements, 
transformation  program  requirements,  data  base  and 
transformation  software  acquisition  costs,  and 
training  requirements  wilL  he  collected.  A 
detailed  anaLysls  wlLl  be  conducted  to  determine 
which  requirements  are  common  among  the  simula¬ 
tors,  which  are  common  for  a  particular  training 
category,  and  which  requirements  are  anticipated 
for  future  applications.  In  addition  the  simula¬ 
tor  Industry  will  be  surveyed  to  determine  what 
advancements  in  the  state-of-the-art  can  he 
expected  that  would  impact  the  form  of  specific, 
simulator  data  bases.  This  task  wllL  provide  the 
basic  data  and  will  establish  the  baseline  from 
which  the  project  development  effort  will  evolve. 
Task  1  wllL  resuLt  In  a  technical  summary 
describing  DoD  simulator  systems  utilizing  digital 
topographic  data  and,  for  each  system,  a  descrip¬ 
tion  of  the  data  base  and  transformation  program 
requirements.  Task  I  will  be  an  In-house 
Government  activity  requiring  the  involvement  of 
each  of  the  three  services  and  is  scheduled  to  bo 
a  9-month  effort. 

Task  2.  F.valuatlon  of  Data  Base  Sources. 

An  evaluation  and  analysis  of  existing  data 
base  sources  wi  l L  be  accomplished  In  parallel  with 
the  Task  1  activities.  Existing  sources  will 
Include  Level  1,  Level  2,  and  Level  V  DMA  data  as 
well  as  other  digital,  photogr ammet r I c ,  and  char; 
sources.  In  addition  to  the  analysis  of  real 
world  data  sources,  an  analysis  of  data  base 
alternatives  e.g.  ,  generic  data  base,  syntheti¬ 
cally  generated  data  bases,  etc,  will  be  accom¬ 


plished.  Task  2  is  Intended  to  he  ^  front  end 

analysis  which  will  provide  Information  i  supi'«>r; 
of  the  later  tasks  of  requl  rent-  n:  s  d»*  t"  i  n  i  :  inn  , 
program  methodology,  and  software  *ie ve  1  ■  >pm.-  . 

Task  2  will  result  In  a  technical  srrur.' 
describing  the  utility,  strong  points,  and  w.-  ik 
points  of  existing  data  base  sources  as  well  -as 
the  feasibility  of  generating  data  bases  f r  m  .on- 
real  worLd  sources  or  bv  combining  real  world  with 
non-real  world  features.  Task  2  will  be  an  i 
house  Government  activity  and  is  scheduled  to  he  i 
IS- mo  .nth  effort. 

Task  3  -  Program  Requirements  Definition 

A  training  evaluation  will  be  accomplished  to 
determine  data  base  and  trans  formal  ton  program 
requirements  as  a  function  of  training  require¬ 
ments.  A  composite  set  of  simulator  data  base 
requirements  will  he  developed,  based  upon  results 
of  the  training  utility  evaluation  data  collected 
in  Task  1  ,  and  the  experience  of  the  tri-service 
working  group  part tc I  pants.  \  major  goal  will  he 
to  define  a  process  that  does  not  stifle  future 
technolog ica 1  innovation  nor  severely  limit  the 
use  of  those  innovations.  It  wl L 1  then  be  neces¬ 
sary  to  develop  a  data  base  generation  concept  to 
Identify  which  functions  should  be  accomplished 
during  the  simulator  data  base  creation  process, 
which  functions  should  be  accomplished  hv  a  common 
t rans f ormat  Ion  program  for  each  application  l.e., 
visual,  radar,  or  sensor,  and  which  functions 
should  be  accomplished  in  a  system-unique  environ¬ 
ment,  l.e.,  the  adapt at  ion/ forma 1 1  ing  process. 
The  data  base  generation  concept  wLll  serve  as  the 
basis  for  defining  transformation  program  com¬ 
monality  requirements  and  alternatives.  Task  3 
will  result  In  a  technical  evaluation  of  the 
requirements  for  the  engineering  development  that 
will  follow  In  Task  4,  and  will  be  accomplished 
primarily  by  the  trl-servlce  working  group, 
although  a  limited  amount  of  contract  work  will  be 
considered.  Industry  inputs  will  also  he  soli¬ 
cited  at  this  time.  Task  3  is  scheduled  to  bo  a 
6-month  effort. 

Task  4  -  Program  Methodology 

Once  the  data  base  generation  concept  and  a 
set  of  requirements  for  both  the  data  base  and  the 
t rans f ormat ion  programs  are  established,  the 
program  development  strategy  will  he  defined. 
This  strategy  will  pursue  the  prlmarv  objectives 
of  developing  a  DoD  standard  simulator  data  base 
and  common  transformation  software.  The  task  wllL 
Involve  defining  a  set  of  engineering  development 
activities  that  will  be  directed  toward  the 
program  objectives  and  will  determine  the  me  a  as  by 
which  each  activity  will  be  approached  e.g., 
contract  versus  In-house  Government  work,  which 
service  or  laboratory,  etc.  Task  4  will  be 
accomplished  by  the  trl-servlce  working  group  and 
will  result  In  a  detailed  program  plan  defining 
engineering  development  activities  to  bo 
accomplished  and  technical  spec  I f icat ions  for  the 
development  activities.  Task  *  is  scheduled  to  ho 
6 -month  effort. 

Task  3  -  Data  __  Has  e  \  nd  T  r  -ins  format  inn  Prog  rim 

Devo 1 opme  nt . 

During  Task  3,  the  activities  defined  hv  Task 
4  will  actual Iv  he  accomplished  hv  both  In-house 
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and  contract  efforts, 
will  Inc l ude : 


Spec l f i c  work  ac t  I  v  i  t les 


1.  The  development  of  simulator  data  base1 
generation  software. 

2.  The  development  of  advanced,  multi- 
application  simulator  transformat  Ion  programs. 

3.  The  generation  of  simulator  prototype 
data  base  areas. 

4.  The  evaluation  of  the  prototype  data 
base  areas  on  various  non-real  time  and  real  time 
simulator  training  devices. 

5.  The  development  of  data  base  main¬ 
tenance  methods. 

b.  Detailed  technical  reports  describing 
both  the  development  activity  Itself  and  the 
actual  test  results. 

The  development  activity  may  be  directed 
toward  more  than  one  specific  approach  and  will 
permit  government  evaluation  of  several  different 
alternatives.  A  wide  variety  of  DoD  agencies  will 
play  an  active  part  throughout  the  development  and 
follow-on  testing.  Testing  of  both  the  data  base 
and  transformation  programs  will  Include  eva¬ 
luations  using  both  operational  and  in-house  Image 
processing  systems  i.e.,  DRLMS  and  CIC.  systems, 
reports  describing  both  the  development  activity 
Itself  and  the  actual  test  results.  Task  S  Is 
scheduled  to  he  a  30-month  activity. 


Final  Evaluation  and  Implementation. 


Once  the  data  lv.se  and  trar.s f ormat  ion  program 
alternatives  have  been  developed  and  testing 
completed,  a  final  evaluation  will  be  conducted  bv 
the  trl-servlce  working  group  from  which  an  accep¬ 
table  approach  to  data  base  generation  and  trans¬ 
formation  will  he  selected.  So  that  the  selected 
approach  can  actually  he  utilized  hv  each  of  the 
services,  an  Implementation  plan  will  be  developed 
which  will  provide  the  means  for  an  Integrated  Dol) 
simulator  data  base  generation  capability.  The 
final  products  of  Task  h  will  Include  a  technical 
summary  defining  the  approach  selected  for  simula¬ 
tor  data  base  generation,  transf ormat Ion,  and 
maintenance,  technical  spec l f Icat Ions  defining  the 
requirements  for  simulator  transformation 
programs,  a  simulator  data  base  generation  capabi¬ 
lity  Including  technical  specifications  defining 
the  requirements  for  simulator  data  base  content, 
and  a  final  report  with  recommendations  for  DoD 
Imp lement at  Ion .  Task  f>  Is  scheduled  to  he  a 
1  2-month  ef  fort . 


SUPPORTING  EFFORTS 

Project  28S1  will  take  advantage  of  a  number 
of  ongoing  efforts  to  develop  the  standard  data 
base  and  transformation  software.  These  efforts 
have  Individual Iv  diverse  goals,  hut  all  involve 


•s  IJ  •,  .  -  : 


important  cons ide ra t Ions  ror  data  base  standar¬ 
dization.  Some  of  these  efforts  will  be  discussed 
In  detail. 

High  Resolution  Data  Base 

The  High  Resolution  Data  Rase  (HRDB)'*  also 
known  as  l.evel  V,  is  an  enhanced  culture  data  base 
that  is  now  available  In  prototype  form  from  DMA. 
HRDB  Improvements  over  the  earlier  First  Edition. 
01. MS  include  the  addition  of  roads,  railroads, 
streams,  airport  lighting  and  buovs.  Another 
major  Improvement  Is  the  addition  of  ml c rode sc r l p- 
tors  for  some  types  of  features.  Microdescr l ptors 
provide  additional  information  about  the  com¬ 
position,  or  detailed  makeup,  of  large  homogenous 
OLMS  features. 

ASD  is  evaluating  the  HRDB  prototype  data  to 
determine  Its  ability  to  satisfy  simulator  data 
base  requirements.  The  evaluation  is  making  use 
of  five  small  areas  of  prototype  HRDB  data  which 
have  been  produced  bv  DMA.  The  evaluation  I  nc 1 u- 
des  transformation  of  HRDB  areas  and  generation  of 
static  CIG  scenes.  A  dvnamlc  demonstration  of  the 
C1G  data  bases  on  the  C- 1 30  visual  system  at 
Little  Rock  AFB  Is  Included  along  with  a  KC-13S 
radar  evaluation  at  ASD.  Results  of  the  HRDB  eva¬ 
luation  will  he  available  hv  late  1983.  HRDB  or  a 
derivative  will  likelv  be  one  of  the  major  data 
sources  for  Project  28S1. 

Digital  Multi-Use  Feature  File 

The  mulls!  Multl-Itse  Feature  File  (nMUKF)h  Is 
another  new  prototype  culture  digital  data  base 
from  DMA.  While  this  new  data  base  currently 
exists  onl v  In  the  form  of  a  draft  spec l f t ca t Ion , 
It  probahlv  represents  the  next  step  bevond  the 
HRDB  data  base.  The  DMDFF  is  Intended  to  support 
a  number  of  different  DMA  digital  products  and 
thus  various  levels  of  data  detail  mav  be  con- 
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talned  La  the  data  Hast*.  The  sl.rm*:ure  of  l  he 
DMHFF  enables  storage  and  retrieval  of  mar.v  pro¬ 
ducts  over  the  same  geographical  area  us  {  ng  runino :; 
data  elements  to  describe  features  applicable  to 
these  various  products.  Much  of  the  Impact  of  the 
DMl'FF  will  affect  only  PMA  internal  procedures, 
although  some  format  changes  will  he  required. 
However  users  will  likely  receive  lx*  t  ter  support 
for  a  wider  range  of  applications,  with  some 
changes  in  data  format.  A  number  of  new  features 
and  new  feature  descriptors  will  llkelv  also  be 
prov ided . 


'':.t  i  I  recently,  little  emphasis  was  pi  joed  the 

sv'itematlc  correct  Ion  of  the^e  nr-iMems;  h<  ►wi-v.m' , 
AS!)  has  level  opt’  1  s  it  twain*  to  iut  vnatlca!  1  v  dete.-*. 
near  l  v  all  »c«*urrences  of  mn.nv  ot  the  tvpe^  u 
errors  which  nr.*  pu  rt  leu  I  i  r  lv  hot  he  rso:m*  to  s|t.  i- 
lator  applications.'  The  software  also  nut  criti¬ 
cally  corrects  a  high  percentage  of  these  errors, 
a.od  provides  a:;  Interactive  means  of  u.alvsls  md 
correction  for  the  remaining  errors.  This  soft¬ 
ware  lias  been  used  successfully  by  both  ASP  and 
DMA  to  correct  problems  with  culture  lata  ?  >r 
several  slmul itor  programs. 


Synthetic  Breakup 


Another  effort  being  pursued  at  ASI)  involves 
the  development  of  a  comprehensive  synthetic 
breakup  algorithm.  This  Is  a  technique  to  sta¬ 
tistically  break  up  large  homogeneous  features  as 
provided  by  DMA  Into  representative  distributions 
of  theLr  component  parts.  This  technique  Is  Ini¬ 
tially  being  developed  to  use  the  mlcrodescr i ptor 
Information  provided  in  the  HRDB  data. 

Figure  s  depicts  the  concept  of  the  synthetic 
breakup  process.  On  the  left  Is  the  outline  of  a 
DMA  feature  which  defines  the  boundary  of  a 
housing  area.  1’slng  HRDB  m  1  c  rodesc  r  1  ptor  infor¬ 
mation  supplied  with  this  feature,  the  predominant 
street  pattern  can  be  determined  and  generated. 
Then  a  representative  set  of  buildings  can  be 
distributed  throughout  the  feature  areas.  The 
result  Is  shown  on  the  right. 

Synthetic  breakup  Is  currently  being  developed 
as  a  preprocessing  step  prior  to  transformation. 
It  is  scheduled  to  be  demonstrated  at  ASD  using 
the  HRDB  prototype  data  In  December  1983.  In  the 
future,  this  capability  could  be  Integrated  with 
other  transformation  processes,  and  will  certainly 
be  Included  In  the  standard  data  base  and  trans¬ 
formation  process  where  exact  real  world  ground 
truth  Is  not  a  strLct  requirement.  Although 
synthetic  breakup  does  result  In  data  that  Is  not 
In  one-to-one  cor respondence  with  the  real  world, 
It  has  great  value  In  providing  clutter  Infor¬ 
mation  for  high  resolution  simulator  app L Icat Ions . 


Quality  Control 

Over  the  years  a  number  of  deficiencies  or 
anomalies  have  been  discovered  In  the  DMA  data. 


These  concepts  of  quality  cur.tr  >1  ^  is*  V- 

applied  and  extended  for  Project  .’831  l<»  or  >v  Me  o 
more  comprehensive  malvsls  of  both  terrain  a-*! 
culture  data.  Slml lar  techniques  must  be  designed 
and  applied  to  any  standard  data  base  product  pro¬ 
duced  by  Project  2881. 

Cartographic  Applications  for  Tactical  and 
Strategic  Systems 

The  Cartographic  Applications  for  Tactical  and 
Strategic  Systems  (CATSS)  is  an  effort  bv  the  Air 
Force  Rome  \  l  r  Development  Center  (RADC)  to  for¬ 
mulate  a  comprehensive  list  of  Air  Force  require¬ 
ments  for  digital  cartographic  data.  This  effort 
will  attempt  to  identify  common  requirements  and 
minimize  redundant  development  of  digital  car¬ 
tographic  products.  Project  2H31  personnel  will 
keep  Informed  of  the  results  of  the  CATSS  anal  vs  Is 
and  recommends  t  Ions  In  order  to  Insure  com¬ 
patibility  as  much  as  possible  with  Identified 
common  needs.  The  Project  28  SI  team  will  also 
inform  the  CATSS  program  personnel  of  any  new 
requirements  which  are  needed  to  support  Project 
28 S l  . 


SUMMARY 


The  objective  of  Project  2831  Is  to  develop  a 
DoD  standard  simulator  data  base  and  common  trans¬ 
formation  software  that  will  he  used  for  simulator 
training  devices  requiring  the  use  of  digital 
topographic  data.  The  DoD  standard  simulator  data 
base  will  provide  a  common  source  of  digital 
topographic  data  that  will  be  specifically  com¬ 
piled  to  meet  training  objectives  and  which  mini¬ 
mizes  the  need  to  enhance  DLMS  data  during  the 
data  hase  generat Lon/ trans format  Ion  process  for 
each  Individual  simulator  system.  The  common 
transformation  software  will  attempt  to  reduce  the 
amount  of  system  unique  software  that  will  need  to 
he  developed  for  each  simulator  system.  It  will 
promote  a  greater  degree  of  data  hase  and  software 
compatibility  among  the  many  DoD  simulator 
systems.  The  results  of  the  Project  28S1  promise 
to  he  Improved  simulator  training  capability  at 
reduced  development,  acquisition,  anti  life  cycle 
cost  to  the  government. 
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ABSTRACT 


The  development  of  data  bases  for  computer  image  generation  systems  is  a  time  consuming, 
labor  intensive  process.  While  the  last  ten  years  have  seen  tremendous  advances  in  the 
capabilities  and  capacities  of  computer  image  generation,  comparable  advances  have  not 
occurred  in  the  area  of  data  base  management.  As  visual  systems  can  output  more  scene  detail, 
they  require  data  bases  which  contain  more  information  and  so,  take  longer  to  build.  If  some 
effort  is  not  made  to  develop  methods  to  build  data  bases  more  efficiently,  the  limiting 
factor  for  the  amount  of  detail  contained  in  an  environment  will  be  the  data  base  development 
time.  This  paper  will  discuss  two  projects  currently  underway  at  the  Air  Force  Human 
Resource  Laboratory  (AFHRL),  Williams  Air  Force  Base,  AZ,  which  enable  data  bases  to  be 
developed  much  quicker  by  allowing  the  modelers  to  utilize  work  which  has  been  done  in  the 
past  by  AFHRL  or  other  organizations.  The  first  project  is  the  development  of  software  to 
convert  data  bases  formatted  for  one  visual  system  to  the  format  required  for  another  visual 
system.  The  intermediate  steps  of  'Lis  process  will  utilize  a  "generic  data  base,"  which  is 
simply  a  data  base  which  contains  the  minimum  information  necessary  to  recreate  the 
environment  in  any  format.  The  preliminary  test  of  this  effort  will  be  to  convert  data  bases 
between  the  Advanced  Simulator  for  Pilot  Training  (ASPT)  and  the  F-111B  Visual  System 
Attachment.  If  successful,  the  effort  will  br  extended  to  transform  existing  data  bases  from 
Defense  Mapping  Agency  (DMA)  and  other  visual  simulation  systems  used  by  the  Air  Force,  Army, 
and  Navy.  When  completed,  this  will  alleviate  the  necessity  of  completely  regenerating  the 
same  data  base  by  hand  when  it  is  to  be  used  on  multiple  visual  systems.  The  second  project 
is  the  development  of  a  library  of  models,,  This  library  is  an  on  going  effort  to  create  a 
collection  of  pre-made  models  that  are  accurate,  usable,  and  well  documented.  An  effort  is 
being  made  to  predict  which  models  will  be  required  in  the  future  and  to  create  them  before 
they  are  needed.  The  library  will  alleviate  data  base  modelers  having  to  make  every  model 
from  scratch  every  time  that  model  is  used  in  a  different  data  base.  These  projects  and 
others  also  under  development  at  AFHRL  will  allow  data  bases  in  the  future  to  be  generated 
much  more  efficiently  and  quickly  than  is  currently  possible  for  most  visual  systems. 


INTRODUCTION 

When  Computer  Image  Generations  (CIG)  was 
introduced,  the  limiting  factor  was  the 
processing  power  and  speed  of  the  hardware. 

Since  then,  much  work  has  been  done  in  the 
development  of  faster  and  more  powerful 
hardware,  and  only  limited  work  in  the  area  of 
data  base  development.  Due  to  hardware 
limitations,  early  data  bases  were  small, 
covering  only  a  limited  area  with  relatively  few 
visual  cues.  The  increased  edge  processing 
capabilities  of  current  systems  permit  missions 
to  be  more  complex,  requiring  significantly 
larger  data  bases.  It  is  not  uncommon  today  for 
data  bases  to  cover  areas  of  several  hundred 
thousand  square  miles.  Although  improvements 
have  been  made,  these  data  bases  still  require  a 
proportionally  longer  time  to  build  and  debug. 

A  simpler,  faster,  and  more  automatic  method  of 
creating  and  modifying  data  bases  must  be  found. 

The  goal  of  AFHRL/OT  is  the  improvement  of 
combat  effectiveness  through  flying  training 
related  science  and  technology  development.  To 
help  support  this  goal,  several  different 
computer  image  generators  are  used.  When  a 
different  visual  environment  is  required  for  a 
ri  search  study,  it  must  be  developed  from 
-  ratch.  In  order  to  accomplisth  this,  it  is 
-■  important  to  develop  and  manage  CIG  data 
i.cs.  If  two  image  generators  are  to  display 
visual  environment,  it  must  be 
<■ ’  : "d  separately  for  each  system. 

i-arli  image  generator  has  its  own 
:*•  base  management  system  for  creating 


visual  environments.  The  data  base  modeler  must 
learn  all  these  systems  and  use  them  to  build 
visual  environments  as  required  to  support  the 
mission. 

There  are  two  ways  to  speed  up  the  process 
of  data  base  development.  One  is  to  utilize 
work  that  has  been  done  in  the  past.  Another  is 
to  improve  methods  that  will  be  used  to  build 
new  data  bases  or  modify  existing  data  bases. 
This  paper  will  discuss  work  currently  being 
done  at  AFHRL/OT  which  enables  us  to  save  data 
base  development  time  by  using  work  done  in  the 
past. 

There  are  two  projects  underway  which  will 
be  detailed.  The  first  project  is  a  set  of 
programs  to  convert  data  bases  from  one 
real-time  visual  system  to  another.  The  second 
project  discussed  is  the  library  of  standard 
models  currently  being  developed. 

Definitions 

Before  describing  in  detail  the  work  being 
done  at.  AFhRI./OT,  definitions  of  key  terms  will 
be  given. 

A  visual  data  base  is  defined  as  a 
collection  of  numerical  data  which  represents  a 
visual  environment.  This  environment  may  be 
either  an  imaginary  world  or  a  portion  of  the 

real  world. 

The  data  base  is  built  by  using  the 
following  geometric  concepts: 
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Vortex:  A  point  located  in  3-D  space 

Edge:  A  straight  line  segment  between 
two  vertices 

Face:  A  closed  convex  planar  polygon 
( includes  a  color) 

2D  Object:  A  set  of  coplanar  faces 

3D  Object:  A  set  of  faces  which  form  a 
closed  convex  polyhedron 

2D  Model:  A  set  of  2D  objects 

3D  Model :  A  set  of  3D  objects 

Environment:  A  set  of  models  that 
represents  a  visual  scene 

Level  of  Detail  (LOD):  Each  model  in  an 
environment  can  be  modeled  in  multiple  levels  of 
detail,  each  with  a  different  amount  of 
complexity.  In  real  time,  the  visual  system 
displays  the  appropriate  LOD  for  each  model  in 
the  environment.  Proper  use  of  feature  results 
in  the  elimination  from  processing  those  edges, 
faces,  and  objects  too  small  to  be  perceived. 

ASPT  Visual  System 

ASPT  has  a  2,500  edge  monochrome  visual 
system.  It  uses  seven  CRTs  to  display  a  300° 
horizontal  by  110°  vertical  field  of  view. 

The  environment  can  be  as  large  as  1256  x  1256 
nautical  miles.  In  a  visual  environment,  there 
may  be  at  most  300,000  edges,  40,000  objects, 
and  2,000  models.  The  real-time  visual  system 
can  display  at  most  2,560  edges,  512  objects, 
and  200  models  per  frame.  The  ASPT  visual 
system  allows  three  levels  of  detail  per  model. 
The  switching  distance  from  one  level  to  the 
next  is  a  function  of  the  aircraft  altitude 
above  ground,  the  distance  to  the  center  of  the 
model,  and  the  size  of  the  model.  ASPT  uses 
shades  of  gray  for  painting  the  displayed 
faces.  The  scale  goes  from  0  (very  black)  to  63 
(very  white). 

DIG  Visual  System 


The  F-lll  DIG  has  an  8,000  edge  color  visual 
system.  It  uses  three  channels  to  display  a  125° 
horizontal  by  36°  vertical  field  of  view.  The 
environment  can  be  as  large  as  600  x  600 
nautical  miles.  In  a  visual  environment  there 
may  be  at  most  2,680  models.  The  DIG  Visual 
System  Attachment  (VSA)  allows  32  levels  of 
detail  per  model.  The  switching  distance  from 
one  level  to  the  next  is  specified  by  the  data 
base  modeler.  The  DIG  has  4,006  different 
colors  available  for  real-time  use. 


a  data  base  which  can  be  used  in  computer  image 
generation. 

Until  recently,  the  following  procedure  was 
used  to  build  data  bases:  The  modeler  would 
manually  digitize  source  information  (such  as 
maps,  photographs,  etc.)  and  then  punch  that 
information  on  to  computer  cards.  The  cards 
would  be  run  through  several  offline  programs, 
and  the  data  base  would  be  output  to  a  disk 
file.  The  modeler  would  then  have  to  use  the 
real-time  visual  system  to  look  at  the  data  base 
and  check  for  errors  such  as  wrong  colors, 
models  placed  in  the  wrong  locations,  or  other 
mathematical  errors.  If  any  errors  were  found, 
the  source  data  would  be  changed  and  the  entire 
process  repeated.  Figure  1  illustrates  this 
process.  Although  improvements  have  been  made 
in  most  data  base  modeling  systems,  the  same 
basic  procedure  is  followed. 
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Figure  1  Typical  Data  Base  Modeling  Procedure 


DATA  BASE  CONVERSION 

Currently  each  real-time  visual  system  uses 
a  data  base  with  a  unique  format.  This  is 
necessary  to  allow  it  to  retrieve  the 
information  contained  in  the  data  base  most 
efficiently.  However,  although  different 
formats  are  used,  the  various  system  data  bases 
contain  the  same  basic  information.  This 
information  includes  the  definition  of  the 
shape,  location,  and  color  of  each  object  in  the 
environment.  Thus,  it  should  be  possible  to  use 
the  information  contained  in  the  data  base  of 
one  visual  system  to  create  a  data  base 
formatted  for  another  visual  system.  This  is 
the  idea  behind  the  data  base  conversion 
project;  to  utilize  work  done  in  the  past. 


Data  Base  Modeling 

Modeling  is  the  art/science  of  defining  the 
visual  environment  which  will  become  a  data 
base.  The  data  base  modeler,  in  conjunction 
with  the  researcher,  is  responsible  for 
identifying  the  important  visual  cues  in  the 
environment.  The  modeler  then  defines  them  in 
terms  of  a  three-dimensional  coordinate  system 
and  submits  them  to  a  set  of  modeling  programs. 
These  programs  take  this  input  data  and  generate 


Two  different  approaches  to  this  conversion 
process  were  considered.  The  first  was  to 
develop  software  which  would  directly  convert 
the  data  base  of  one  visual  system  to  that  of 
another.  This  was  rejected  since  the  number  of 
programs  required  tc  do  this  would  grow  almost 
exponential ly  as  more  visual  systems  were 
added.  The  second  approach  involves  the  use  of 
a  data  base  with  a  generic  format  as  a  kernel  ur 
core.  Two  programs  would  have  to  be  written  for 
each  visual  system  that  a  data  base  is  to  be 
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converted  to  or  from.  The  first  program  would 
convert  the  data  base  from  its  native  format  to 
the  format  of  the  generic  data  base.  The  second 
program  converts  from  the  generic  data  base  to 
one  used  by  that  visual  system.  The  second 
approach  was  chosen  since  it  has  the  flexibility 
built  in  to  allow  the  number  of  visual  systems 
to  expand.  Figure  2  illustrates  this  concept. 
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Figure  2  Data  Base  Conversion  System 


It  was  decided  to  use  several  phases  in  the 
development  of  this  project.  Phase  1  would 
allow  the  conversion  of  data  bases  between  two 
specific  visual  systems.  The  visual  systems 
selected  were  the  General  Electric  Advanced 
Simulator  for  Pilot  Training  (ASPT)  and  the 
Singer-Link  Digital  Image  Generator  (DIG)  for 
the  F-111B  Visual  System  Attachment.  This  is 
shown  in  Figure  3.  These  systems  were  chosen 
for  two  basic  reasons.  First,  they  were  both  on 
site  at  AFHRL  which  allowed  for  more  convenient 
testing.  Second,  there  were  significant 
differences  in  the  format  of  these  data  bases, 
so  that  a  good  test  case  could  be  provided. 
Details  on  these  two  visual  systems  can  be  found 
in  the  Introduction. 


Figure  3  Phase  1  of  Data  Base  Conversion 


Phase  1  would  be  used  to  demonstrate  the 
feasibility  of  the  concept.  It  would  also  be 
used  to  explore  different  formats  of  the  generic 
data  base  as  well  as  different  techniques  to 
perform  the  conversion. 

Phase  2  would  take  the  lessons  learned  in 
Phase  1  and  develop  a  more  general  format.  This 
would  allow  the  conversion  of  features  not  found 
in  either  the  ASPT  or  DIG. 

The  first  step  of  Phase  1  was  the 
development  of  a  generic  data  base  format.  What 
was  required  for  this  data  base  was  enough 
geometric  information  to  describe  the  visual 
environment  exactly.  This  information  was 
obtained  by  means  of  a  thorough  analysis  of  the 
two  visual  systems  to  be  converted.  The  data 
base  formats  of  several  other  visual  systems 
were  also  reviewed  at  this  time  so  that  the 
generic  format  could  be  easily  modifiable. 

The  generic  data  base  contains  enough 
information  to  allow  the  creation  of  a  data  base 
for  either  the  ASPT  or  DIG  visual  systems. 
Basically,  this  data  base  can  be  thought  of  as 
having  two  parts.  The  first  is  a  directory 
which  contains  the  model  name  and  disk  location 
of  its  information.  The  second  part  is  the 
geometric  data  of  each  model.  This  data  is 
composed  of  general  model  data,  general  object 
data,  face  data,  and  vertex  data.  Examples  of 
the  type  of  data  in  the  generic  data  base  are 
given  in  Figure  #4. 
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Figure  4  Generic  Data  Base  Information 


The  rest  of  Phase  1  is  concerned  with  the 
development  of  a  set  of  programs  to  perform  the 
conversion  of  a  data  base  between  the  two  visual 
systems  chosen.  This  consists  of  four  programs 
which  perform  the  following  functions:  convert 
an  ASPT  data  base  to  the  generic  format;  convert 
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a  DIG  data  base  to  the  generic  format;  convert  a 
generic  data  base  to  the  ASPT  format;  and 
convert  a  generic  data  base  to  the  DIG  format. 

Currently,  two  of  the  four  programs  have 
been  written.  The  first  allows  the  conversion 
of  an  ASPT  data  base  to  the  generic  format.  The 
second  allows  the  conversion  of  a  generic  data 
base  to  the  DIG  format. 

The  programs  have  been  designed  so  that  they 
will  not  have  to  be  completely  rewritten  if  the 
format  of  the  generic  data  base  is  changed. 

When  the  programs  were  coded,  an  effort  was  made 
to  insure  that  the  programs  were  modularized. 
Also,  each  routine  has  been  well  documented  to 
make  any  future  changes  easy  to  implement.  The 
programs  are  written  almost  entirely  in 
FORTRAN.  The  only  assembly  language  routines 
perform  tasks  such  as  disk  I/O.  These  programs 
are  also  relatively  short,  each  being  less  than 
1000  lines  of  code. 

Once  the  data  base  has  been  converted,  there 
is  still  work  for  the  modeler  to  do.  The 
differences  between  different  computer  image 
generators  must  be  accounted  for  if  the 
environment  is  to  make  maximum  use  of  the 
capabilities  of  the  visual  system.  The  most 
common  task  to  be  performed  is  the  addition  or 
deletion  of  models.  If  the  receiving  system  has 
a  higher  edge  capacity  than  the  originating 
system,  then  models  should  be  added  to  the  data 
base.  However,  if  the  receiving  system  has  a 
lower  edge  capacity  than  the  originating  system, 
models  should  be  deleted  so  the  image  generator 
is  not  overloaded  constantly.  Colors  of  faces 
may  also  have  to  be  adjusted.  This  is  most 
important  when  the  originating  system  is 
monochrome  and  the  receiving  system  has  full 
color.  However,  some  adjustment  will  also  be 
necessary  in  the  conversion  between  two  color 
visual  systems  since  their  color  tables  will 
probably  be  different.  In  addition,  some 
"tweaking11  will  need  to  be  done  on  the  real-time 
variables  in  the  data  base.  These  real-time 
variables  include  such  things  as  the  distances 
at  which  models  appear  and  disappear  in  the 
visual  scene.  The  conversion  program  computes 
default  values  for  these  and  places  them  in  the 
data  base.  However,  the  defaults  will 
occasionally  need  to  be  adjusted. 

A  data  base  originally  built  for  use  on  the 
ASPT  has  been  successfully  converted  to  run  on 
the  DIG.  In  spite  of  the  work  required  to  make 
maximum  use  of  the  OIG's  capacity,  the  automatic 
conversion  saved  over  50T  of  the  time  required 
to  rebuild  the  data  base  by  hand.  If  one  would 
be  satisfied  with  seeing  a  2500  edge,  monochrome 
scene  on  the  DIG,  very  little  work  need  be  done 
after  the  conversion  is  complete  and  much  more 
time  would  be  saved. 

Currently,  the  last  two  programs  of  Phase  1 
are  being  designed.  Once  these  two  programs  are 
complete,  a  data  base  created  on  the  DIG  will  be 
converted  and  flown  on  the  ASPT.  At  this  point, 
we  will  have  the  capability  to  transfer  data 
bases  between  the  ASPT  and  the  DIG. 


Phase  2 

Once  Phase  1  is  completed,  work  can  begin  on 
Phase  2.  This  will  be  an  expansion  of  Phase  1 
to  allow  the  conversion  of  data  bases  between 
any  visual  system  at  AFHRL.  Phase  2  will  use 
the  same  approach  as  Phase  1;  the  major  differ¬ 
ence  will  be  in  the  format  of  the  generic  data 
base.  The  format  of  the  generic  data  base  will 
need  to  be  expanded  to  include  information  not 
used  by  the  ASPT  or  DIG  but  needed  for  the  other 
systems.  This  information  includes  such  things 
as  DMA  terrain  and  culture,  texture,  and 
circular  features.  One  area  which  will  require 
thorough  investigation  is  the  role  that  DMA 
terrain  and  culture  will  play  in  the  generic 
data  base.  There  are  both  pros  and  cons  to 
including  this  information  in  the  data  base. 
Another  area  to  be  investigated  is  the 
possibility  of  converting  between  visual,  FLIR, 
and  radar  systems  to  a  limited  extent. 

MODEL  LIBRARY 

The  second  project  to  be  discussed  is  the 
development  of  a  model  library.  This  library 
includes  digitized  models  of  various  military 
vehicles  and  aircraft  (mostly  Soviet  and  U.S.). 
The  digitized  models  are  designed  to  be  used  on 
edge/face  based  aircraft  simulation  systems. 

The  models  are  made  as  edge-efficient  as 
possible  while  still  retaining  sufficient  detail 
for  vehicle  and  aircraft  identification. 

Without  this  library,  models  were  made  only  when 
they  were  required  in  an  environment.  When  the 
same  model  was  later  required  in  another 
environment,  the  model  was  essentially  remade 
from  scratch.  What  is  normally  done  is  to 
accumulate  models  as  they  are  generated  for  an 
environment.  In  addition  to  this,  we  are 
predicting  what  models  will  be  needed  in  future 
visual  environments  and  then  developing  these 
models  into  a  readily  accessible  library.  This 
library  will  allow  data  base  modelers  to 
generate  visual  environments  more  quickly  and 
efficiently. 

The  models  are  being  created  on  the  ASPT 
visual  system.  Therefore,  the  models  are 
designed  and  tested  to  the  format  and 
restrictions  of  the  ASPT  visual  system.  These 
were  described  in  the  Introduction. 

When  creating  a  visual  environment,  some 
models  tend  to  be  more  of  a  modeling  problem 
than  others,  and  so,  take  longer  to  build. 

Unlike  most  models  used  in  an  environment, 
vehicles  and  aircraft  require  more  modeler 
finesse  to  be  efficiently  and  accurately 
represented.  Source  data  in  the  form  of 
photographs,  blueprints,  and  dimensions  is  an 
absolute  necessity.  The  identifying  features 
for  these  models  play  an  important  role. 

Relative  dimensions  and  angles  require  much  more 
consideration  than  they  would  for  models  such  as 
buildings.  Since  these  models  tend  to  be  more 
complicated  then  others,  significantly  more 
development  time  is  required.  Assigning  gray 
shades  to  faces  can  be  tricky.  For  example,  the 
top  of  an  aircraft's  wing  should  not  be  the  same 
shade  as  the  side  or  top  of  the  fuselage. 
Separation  planes  required  for  object  priority 
within  the  model  tend  to  be  a  problem  for 
vehicle  and  aircraft  models.  Since  these 


vehicles  and  aircraft  are  likely  candidates  for 
"moving"  models,  real-time  translation  and 
rotation  needs  to  be  considered.  Having  such 
models  premade  and  properly  documented  in  a 
model  library  can  decrease  the  amount  of  time 
required  to  build  a  visual  environment. 

The  models  in  the  library  are  designed  with 
three  levels  of  detail.  An  explanation  of 
levels  of  detail  can  be  found  in  the  intro¬ 
duction.  A  typical  vehicle  modeled  in  its  most 
detailed  version  is  composed  of  five  to  ten 
objects  with  about  100  edges.  Figure  5  shows  a 
vehicle  as  it  is  typically  modeled  on  ASPT,  and 
Figure  6  is  a  photograph  of  the  actual  vehicle. 

A  typical  aircraft  model  in  its  highest  level  of 
detail  has  13  to  15  objects  composed  of 
approximately  300  edges.  Figure  7  shows  an 
aircraft  as  it  is  typically  modeled  on  ASPT,  and 
Figure  8  shows  the  actual  aircraft.  The 
intermediate  and  least  detailed  levels  tend  to 
have  respectively  60  and  30  percent  of  the 
number  of  objects  and  edges  compared  with  the 
highest  level.  The  lower  two  levels  are 
designed  independently  of  the  highest  level  and 
so  are  not  just  a  stripped  down  version  of  the 
highest  level.  All  models  are  constructed  along 
the  X  axis  of  a  3-D  coordinate  system  with 
positive  Z  defined  as  "up."  The  center  of 
rotation  for  modeled  vehicles  is  at  the  middle 
of  the  vehicle  on  the  ground.  A  modeled 
aircraft’s  center  of  rotation  is  at  the 
aircraft's  approximate  geocenter.  Aircraft  are 
made  in  two  versions,  wheels  up  and  wheels 
down.  Variable  geometry  aircraft  are  modeled 
with  the  wings  in  two  positions,  the  fully  swept 
and  fully  unswept  wing  positions.  The  approach 
typically  taken  in  modeling  is  to  be  more 
concerned  with  how  "pretty"  a  model  is  and  less 
concerned  with  how  edge  efficient  it  is.  Since 
our  goal  is  to  create  visual  cues  necessary  to 
perform  a  specific  task  (and  not  to  sell  a 
visual  system),  the  models  are  designed  to  be 
edge  efficient  yet  easily  identifiable.  Instead 
of  having  one  or  two  "pretty"  models  in  a  scene, 
we  can  have  many  less  detailed  but  still  useful 
models.  It  currently  takes  about  two  weeks  to 
design,  code,  debug,  visually  test,  and  document 
a  model . 


Figure  5  Vehicle  Modeled  on  ASPT 
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Figure  6  Actual  Vehicle 
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Since  it  is  intended  that  these  models  be 
used  for  multiple  purposes,  appropriate 
documentation  is  necessary.  Documentation  for 
models  is  available  in  the  form  of  computer 
plots,  formatted  listings  of  the  geometric 
information  describing  the  model,  and  copies  of 
the  modeler's  design  sketches  of  the  individual 
objects  and  the  completed  model.  Figure  9  is  a 
computer  plot  of  a  completed  aircraft  model. 
Figure  10  is  a  typical  example  of  a  modeler's 
design  sketch  of  an  object.  The  models  are 
stored  in  ASPT  modeling  source  format  on  a  file 
saved  on  a  computer  disk  and  are  easily  listed 
on  a  line  printer.  This  source  data  can  be 
easily  saved  on  magnetic  tape  for  transport  to 
other  simulation  systems.  This  would  allow  the 
vehicle  or  aircraft  to  be  easily  hand  coded  into 
the  modeling  source  format  of  another  visual 
system.  In  this  way,  the  time  consuming  design 
phase  of  the  modeling  would  be  eliminated.  When 
the  conversion  program  is  completed,  the  models 
could  be  converted  automatically  from  ASPT 
format  to  the  correct  format  of  the  receiving 
visual  system.  Using  the  same  software,  models 
could  also  be  entered  directly  into  the  library 
from  a  donating  simulator  system. 


Figure  7  Aircraft  Modeled  on  ASPT 


Ficiure  8  Actual  Aircraft 


Figure  9  Computer  Plot  of  a  Modeled  Aircraft 
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Object  Name  "2501" 


Figure  10  Design  Sketch  of  an  Object 


The  model  library  currently  includes 
approximately  100  completed  models.  An  earlier 
collection  of  ASPT  formatted  digitized  models 
exists  on  computer  cards.  An  effort  is  being 
made  to  transition  these  models  into  the  model 
library.  This  means  insuring  that  all  of  the 
card  oriented  models  meet  the  standards  of  the 
model  library  (three  levels  of  detail, 
documentation,  etc.).  The  models  in  the  library 
are  a  collection  of  work  done  by  several 
modelers.  Therefore  the  style  (artistic 
license)  the  modeler  used  to  represent  the 
vehicle  or  aircraft  may  vary  slightly  from  model 
to  model.  The  models,  when  completed,  are 
readily  available  for  future  study,  test,  and 
training  applications. 

The  library  of  models  is  being  expanded  on  a 
continuing  basis..  Although  the  format  of  the 
library  models  is  from  the  ASPT,  the  models  can 
be  transformed  into  the  format  of  other  CIG 
visual  systems  with  relative  ease.  The  thorough 
documentation  available  makes  the  models  easy  to 
be  modified  as  needed.  The  library  currently 
exists  and  is  being  used  for  on-going  research 
and  development.  The  models  can  be  used  for  a 
variety  of  purposes.  This  model  library  will 
decrease  database  development  time  by  about  two 
weeks  for  each  model  used  from  the  library. 
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ABSTRACT 

The  U.S.  Navy  is  currently  developing  a  Battle  Group  Tactical  Trainer  ( BGTT ) 
which  provides  experiential  war  gaming  exercises  to  Naval  Officers  engaged  in  tactical 
decision  making  and  planning  courses.  A  major  design  goal  for  the  program  is  to 
simplify  the  man-computer  interface  such  that  players  and  controllers  with  little  or 
no  computer  training  can  interact  extensively  with  the  BGTT  data  base.  One  step  in 
the  design  process  was  to  conduct  a  human  engineering  analysis  of  the  BGTT's  objec¬ 

tives,  system  functions,  information  flow,  information  processing  requirements  and 
user  requirements,  and  make  hardware  and  software  recommendations  that  would  assist  in 
the  achievement  of  this  goal.  This  paper  discusses  the  recommended  hardware  and 

software  features  required  to  simplify  operator  interface  with  the  training  system. 

INTRODUCTION  SYSTEM  MISSION 

The  U.S.  Navy  is  currently  developing  a  The  BGTT  system  objectives  will  be  accora- 

Battle  Group  Tactical  Trainer  (BGTT)  which  pro-  plished  in  a  unique  environment  which  will 

vides  experiential  training  through  war  gaming  allow  experiential  decision  making  training, 

exercises  to  Naval  Officers  engaged  in  tactical  This  environment  requires  part ic ipat ion  from 

decision  making  and  planning  courses.  The  players  and  controllers, 

trainer  will  afford  the  opportunity  for  offi¬ 
cers  (players)  to  make  real-time  tactical  Mission  for  Players 

decisions  and  experience  the  impact  of  these 

decisions.  This  tactical  operation  performance  The  participants  in  BGTT  will  be  senior 

will  be  extensively  monitored  and  evaluated  by  Naval  officers  and  their  principal  assistants 

a  control  group  (controllers)  for  effectiveness  participating  in  tactical  training  courses, 

and  fulfillment  of  curricula  objectives.  The  mission  for  the  players  is  to  improve  their 

operational  tactical  decision  making  skills 
A  major  design  goal  for  the  program  is  to  through  practicing  these  skills  in  various 

simplify  the  man-comput u r  interface  such  that  tactical  situations  including  simulated,  high 

players  and  controllers  with  little  or  no  compu-  threat  environments.  This  gaming  environment 

ter  training  can  interact  extensively  with  the  requires  participants  to  plan,  execute  and 

BGTT  data  base.  One  step  in  the  design  process  evaluate  tactical  operations, 

was  to  conduct  a  human  engineering  analysis  of 

the  BGTT's  objectives,  system  functions,  infor-  Mission  for  Control  Group 

mation  flow,  information  processing  require¬ 
ments  and  user  requirements  and  to  make  hard-  To  support  the  BGTT  objectives,  a  control 

ware  and  software  recommends t ions  that  would  group  staff  is  required  to  instruct,  monitor 

assist  in  the  achievement  of  this  goal.  and  assist  the  players.  At  times,  designated 

control  group  personnel  may  also  be  required  to 
The  human  engineering  analysis  followed  participate  in  the  war  game  as  opposing  forces 

the  classical  approach  per  MIL-H-46855.  System  to  the  players.  The  mission  of  the  control 

functions  were  determined  based  on  the  mission  group  is  to  provide  the  players  with  a  meaning- 

of  the  training  system.  These  functions  were  ful  war  game  experience,  monitor  player  perfor- 

allocated  to  players,  controllers  and  the  nance ,  and  provide  feedback,  both  during  and 

trainer  based  on  general  human  engineering  prin-  after  the  game,  allowing  players  to  profit  from 

ciples.  An  extensive  analysis  was  performed  of  the  experience  and  improve  their  operational 

the  information  input  and  output  requirements  performance, 

for  both  players  and  controllers.  Hardware  and 

software  were  then  recommended  which  would  CRITICAL  TASK  ANALYSIS 

provide  players  and  controllers  the  most 

efficient  and  cost-effective  access  to  the  A  task  listing  for  tht  player  group  which 

required  information.  Detailed  discussions  of  outlined  the  duties  of  the  warfare  commander/ 

the  human  engineering  analysis  leading  to  the  coordinator  during  the  planning  and  execution 

architecture  recommendations  are  contained  in  phases  of  their  jobs  was  supplied  by  the  spon- 

Wa 1  drop ,  McDonald,  and  Barry  (  1983).  sor .  A  Critical  Task  Analysis  ( CTA )  was 


required  tor  the  i-murnl  group  because  th«*ir 
duties  had  not  yet  been  defined  with  re  f  e  ri-ni*’ 
to  the  BGTr.  The  tasks  addressed  in  the  ('FA 
examined  the  functions  required  of  the  control 
group  to  support  the  training  objectives  tor 
BGTT.  This  task  analysis  examined  the  duties 
to  be  performed  by  the  staff,  the  information 
necessary,  and  the  additional  trainer  support 
required  tor  task  completion. 

The  task  analysis  detailed  control  group 
information  requirements  for  completion  of  each 
task.  This  was  a  direct  input  to  the  Human 
Engineering  System  Analysis  which  examined  how 
to  provide  access  to  information  in  an  easily 
retrievable  manner. 

Task  Analysis  Procedures 

Data  on  the  job  requirements  for  the  con¬ 
trol  group  were  systematically  gathered  from 
BGTT  objectives,  c  irreiit  duties  of  training 
personnel  and  other  war  gaming  systems.  In 
conjunction  with  obtaining  current  job  specific 
data,  the  tasks  of  current  training  personnel 
were  derived  through  interviews  with  subject 
matter  experts  (SMEs). 

SYSTEM  ANALYSIS 

The  in  format iona l  requirements  for  both 
players  and  controllers  were  identified  by 
gaming  phase  (Briefing,  Planning,  Execution, 
and  Debriefing).  The  player  tasks  were 
prepared  based  on  operational  duties  and  were 
contained  in  a  classified  document.  These 
tasks  were  modified  and  detailed  for  the  gaming 
environment  in  an  unclassified  form.  The 
controller  tasks  were  obtained  from  the  Control 
Group  CTA.  The  System  Analysis  examined 
architecture  configurations  to  fulfill  task 
requ i rements . 

Function  Allocation 

The  purpose  of  the  function  allocation  was 
to  initially  allocate  functions  to  man  (players 
and  control  group),  machine  (BGTT  computer  and 
peripherals)  or  both,  such  that  the  overall  mis¬ 
sion  of  the  training  system  can  be  fulfilled  in 
the  most  cost-effective  manner.  The  functions 
to  be  allocated  were  obtained  from  the  player 
and  controller  task  analyses.  The  allocations 
were  based  on  general  man-machine  capabilities 
and  limitations  and  the  mission  of  the  BGTr 
Training  System. 

Two  unique  characteristics  of  the  BGTr 
mission  were  important  to  the  function 
allocation  process.  Since  the  primary  mission 
is  to  allow  warfare  commanders/coord  inat  <»rs  and 
their  staffs  the  opportunity  to  make  decisions, 
none  of  their  decisions  or  actions  would  be 
allocated  to  the  computer.  However,  Battle 
Group  members  above  and  below  this  level  will 
not  be  included  as  players,  and  their  decisions 
and  actions  must  be  performed  by  the  BGTT 
train'.ng  system  (computer  and  control  group). 

A  second  uniqje  characteristic  concerned 
the  fact  that  BGTT  had  been  described  as  an 
experiential  trainer;  thus,  player  performance 


could  not  be  evaluated  based  on  pre-se!  rigid 
criteria.  Consequently,  evaluation  ot  player 
performance  was  allocated  entirely  to  t  h«- 
control  group.  However,  the  rout  ine  recording 
of  game  events,  as  we l [  as  provision  of 
detailed  information  on  student  actions,  was 
allocated  to  man  and  machine  based  on  general 
human  factors  principles. 

Allocation  of  Functions  to  Players 

After  review  of  the  human  factors  princi¬ 
ples  ,  allocation  of  functions  to  players  was 
straightforward.  All  functions  normally  per¬ 
formed  by  the  Battle  Group  Commander/Composite 
Warfare  Commanders  (BGC/CWC)  and  their  immedi¬ 
ate  staffs  were  allocated  to  the  players. 

Allocation  of  Functions  to  Trainer  and  Con- 
trol  Group 

Al!  functions  involving  the  generation  ot 
information  external  to  the  BGC/CWC  structure 
(mission,  historical  threat,  geopolitical 
situation,  rules  of  engagement,  environment) 
were  allocated  to  the  BGTT  Training  System 
(computer  and  control  group).  All  functions 
involving  the  decisions  and  actions  normally 
executed  (in  accordance  with  Command  Staff 
orders)  by  officers  and  enlisted  personnel 
below  the  participating  officers  (platform 
movement,  enemy  engagement,  logistics)  were 
allocated  to  the  BGTT  Training  System.  All 
functions  involving  determination  of  engagement 
outcomes  and  assessment  of  player  performance 
were  allocated  to  the  BGTT  Training  System. 

Once  the  BGTT  Training  System  functions 
were  allocated  based  on  mission,  these  func¬ 
tions  were  then  allocated  to  man  (control 
group)  and  machine  based  on  human  factors 

principles.  Primary  and  support  responsibil¬ 
ities  for  each  task  in  the  Control  Group 

Critical  Task  Analysis  were  allocated  based  on 
the  human  factors  principles. 

Information  Flow  Requirements 

The  initial  allocation  of  functions  led  to 
the  examination  of  information  flow  require¬ 
ments.  The  primary  functions  of  a  warfare  com¬ 
mander  are  to  gather  information,  assess  its 

importance,  make  decisions  and  relay  this  new 

information  to  other  members  of  the  battle 

group.  Likewise,  the  control  group  personnel 
must  access  and  disseminate  a  great  deal  of 

information  in  order  to  perform  their  job. 

Consequently,  understanding  BGTT  player  and  con¬ 
troller  information  input  and  output  require¬ 
ments  is  critical  to  equipment  identifications. 
The  information  input  and  output  requirements 
for  players  and  controllers  were  detailed  and 
de  f  i  ned . 

player  Information  Requiremen  ^ 

To  perform  Briefing,  P  aiming,  Execution 
.m  d  Debriefing  Phase  tasks,  the  players  must 
receive  and  provide  specific  information.  The 
BGTT  Training  System  must  pro’ide  tins  informa¬ 
tion  in  a  readily  usable  form  in  order  to  com¬ 
plete  its  mission.  Player  information  input 
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Player  information  requirements  for  each 
phase  were  presented  in  tabular  format.  Each 
phase  had  four  tables  associated  with  the  infor¬ 
mation  requirements  for  that  phase,  i.e.,  infor¬ 
mation  input  requirements  by  task,  input  defin¬ 
itions,  information  output  requirements  by 
task,  and  output  definitions.  Table  I  provides 
an  excerpt  from  one  set  of  informat  ion  require¬ 
ments.  The  player  execution  tasks  are  listed 
across  the  top  (direct  reference  to  classified 
task  listing)  and  the  information  inputs 
required  to  complete  these  tasks  on  the  left 
side.  The  X*s  ii.  the  table  indicate  what 
information  is  required  to  complete  each  sep¬ 
arate  task. 

Equipment  Ident  i  f icat ion 


l  the  analysis  process  was 
to  access  and  output  the 
most  efficient  means 


The 

and  outputting  information  depend- 
on  the  informat  ion  update  rate  and 


The  next  step  i 
to  provide  a  means 
required  information, 
of  accessing 
ed  primarily 
the  form  of  the  information.  The  information 
requirements  previously  detailed  were  analyzed 
for  type  and  update  rate. 

This  analysis  led  to  the  recommendation 
that  each  player  station  include  the  following 
hardware : 

o  An  Alphanumeric  Display 

o  A  Standard  ASCII  Keyboard  and  Keypad 
o  A  Graphics  Display  with  Touch  Screen 

o  An  Alphanumeric  Printer 

o  A  Game  Book 

o  A  Secure  Telephone 

o  A  Work  Surface  for  Maps  and  Hardcopy 

o  Facilities  for  Storing  and  Retrieving 
Hardcopy 

The  control  group  equipment  identification 
was  based  on  the  same  information  access  and 
output  principles  used  in  the  player  section. 
The  analysis  led  to  the  recommendation  that 
each  station  contain  the  same  equipment  as  a 
student  station  plus  the  following  hardware: 
o  A  Headset 

o  A  Graphics  Printer 

o  Access  to  a  Word  Processing  System 
o  Access  to  an  Overhead  Projector  and 
Screen  and  Viewgraph  Production  Means 

SOFTWARE  REQUIREMENTS 

Once  the  information  requirements  and  hard¬ 
ware  recommenda t ions  were  completed,  an  exten¬ 
sive  literature  search  was  conducted  on  man- 
computer  interaction.  The  software  recommenda¬ 
tions  in  this  paper  represent  software  features 
shown  to  be  effective  in  recent  research 
reports  and  design  manuals  and  which  will 
provide  BGTT  players  and  controllers  the  most 
efficient  and  cost-effective  means  of  accessing 
and  manipulating  the  required  information. 
Software  requirements  for  BGTT  are  discussed 
under  the  heading  of  Query  Language,  Dialogue, 
Menu  Design,  Screen  Formats,  and  Error- 
Hand  ling. 
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Query  Language 

There  are  a  number  of  query  languages 
available  which  could  conceivably  be  utilised 
by  BGTT.  The  first  option  is  natural  language 
entry  of  requests.  Unfortunately,  "human  commu¬ 
nication  is  characterized  by  ungrammat ica 1 
utterances  and  syntactic  and  semantic  ambigu¬ 
ities"  (Ramsey,  1979).  System  performance  can 
be  improved  by  constraining  the  allowable 
syntax  of  the  natural  language.  However,  the 
naturalness  of  the  language  encourages  the  user 
to  use  syntax  outside  the  constraints,  causing 
errors  that  are  hard  to  explain  Co  the  user. 
Natural  Language  input  is  slow,  error-prone  and 
requires  use  of  the  keyboard.  Natural  language 
input  of  commands  is  not  a  viable  alternative. 

Another  option  is  to  use  some  of  the  sim¬ 
ple  computer  query  languages  based  on  a  rela¬ 
tional  data  base  ( Shne  iderraan ,  1 980 ;  Thomas  & 
Gould,  1975;  Zloof,  1975).  These  query  lan¬ 
guages  were  developed  for  the  infrequent  user 
and  were  intended  primarily  for  management 
information  systems.  Simple  and  medium  complex¬ 
ity  requests  in  the  Query  by  Example 
use  tables  to  simplify  categories,  and 
interest  are  straightforward.  More 
requests  require  the  user  to  remember 
special  characters  and  symbols.  This 
does  not  apply  to  BGTT  because  information 
requests  are  not  complex  enough,  and  there  are 
too  many  categories  of  information  to  present 
even  a  small  fraction  of  the  tables  on  a  screen 
at  one  time. 


approach 
links  of 
comp  1  ex 
and  use 
approach 


Dialogue 


One  of  the  most  important  cons iderat ions 
is  the  type  o  f  dialogue  between  the  user  and 
the  training  system.  The  three  types  of  dia¬ 
logue  are  computer-ini t iated ,  user- in i t iated 
and  mixed-initiative.  In  computer- in i t iated 
dialogue  all  interactions  are  initiated  by 
computer  through  prompts  for  the  requires, 
input.  Conversely,  in  user- in i t iat ed  dialogue, 
the  user  enters  commands  from  memory  and  the 
computer  responds.  In  mixed-in i t iat i ve ,  either 
the  user  or  computer  may  initiate  the  dialogue. 
Compu ter- in i t iated  dialogue  is  the  most  effec¬ 
tive  means  of  interaction  for  the  untrained 
user  (Parrish,  Gates,  &  Munger  1981;  Ramsey  & 
Atwood,  1979;  and  Shneiderman,  1980).  In 
addition  to  reducing  errors  and  number  of 
required  key  strokes,  computer-initiated 
prompts  implicitly  convey  to  the  user  a  mental 
n.odel  of  the  system's  dialogue  structure  and 
remind  the  user  of  unused  commands.  Thus,  as 
the  users  interact  with  the  computer,  they 
learn  where  the  information  is  and  the  required 
pathway  to  reach  it. 


Howeve r , 
c  i  e  n  t ,  their 
I  ogue  d  in i n i s hes  . 


as  t  he  users  become  more  profi- 
need  for  computer- ini t iated  dia- 
F.xperienced  users  prefer  to 


enter  a  single  command  from  memory  (user- 
initiated  dialogue)  and  go  directly  to  the 
required  unit  of  information.  Since  the  BGTT 
will  be  used  by  inexperienced  players  and 
control  group  personnel,  as  well  as  experienced 
operators,  the  system  should  be  designed  for 


...  ...  ........  .  ......  .............. 


both  computer  — uut  iated  and  user-nut  iated 
d i a logue . 

Ramsey  and  Atwood  (1979)  indicate  that  a 
computer  system  that  uses  both  computer-initi¬ 
ated  and  user- ini t iated  dialogue  works  quite 
well  except  for  one  problem.  As  users  become 
more  experienced,  they  are  annoyed  by  the 

computer-initiated  dialogue  but  have  not  yet 
memorized  the  query  language  for  user-initiat¬ 
ed  dialogue.  A  means  is  required  for  a  smooth 
transition  between  computer- in  it iated  and  user- 
initiated  dialogue. 

It  is  recommended  that  the  BGTT  allow  com¬ 
puter-  in i t  iated  or  user- in i t iat ed  dialogue  at 

user  option.  For  the  inexperienced  user,  all 
interactions  will  be  menu  driven  and  the  user 
could  select  the  desired  option  by  way  of  a 
touch  screen.  Optional  displays  should  be 

presented  in  a  hierarchy,  allowing  users  to 
work  their  way  through  the  options  to  the 

desired  display.  When  the  user  touches  the 
desired  display,  it  will  appear  along  with  its 
title  and  four  letter  abbreviated  title.  As 

users  interact  with  the  system,  they  will 

become  familiar  with  the  available  display.-*  and 
their  abbreviated  titles.  The  more  experienced 
user  may  choose  to  type  in  from  memory  the  lour 
letter  abbreviated  title  of  a  display  that 
would  require  three  or  four  steps  to  reach  by 
selecting  options  on  menus.  A  tuliy  experi¬ 
enced  operator  will  be  able  to  access  a  desired 
display  by  typing  in  a  single  four  letter 
command.  If  the  operator  forgets  the  title  of 
a  desired  display,  he  can  sequence  through  Lhe 
menus  by  using  the  touch  screen. 

Menu  Design 

Mace,  Harrison,  and  Sequin  (1979)  conduct¬ 
ed  a  study  of  input  errors  in  automated  battle¬ 
field  information  systems  and  found  that  the 
labeling  of  menu  opt  ions  had  a  major  impact. 
Labeling  menu  options  with  full  English  words 
produced  the  lowest  error  rate  but  tended  to 
clutter  the  display  and  slow  the  responses. 
Using  abbreviations  and  mnemonics  produced  few 
additional  errors  and  reduced  display  clutter. 
The  use  of  nonsense  codes  (e.g.,  A2 )  referenced 
in  a  user  manual  produced  poor  recognition  and 
recall  and  led  to  high  error  rates. 
Abbreviations  and  mnemonics  are  generally 
suitable  inputs  in  must  situations,  because 
abbreviated  equivalents  of  English  words  are 
easily  recognized.  The  recall  of  abbrevi¬ 
ations  and  mnemonics  ran  be  facilitated  by 
standardizing  their  length  and  introducing 
coding  conventions  which  are  consistently 
employed .  Moses  and  Potash  (1979)  found  that 
simple  truncation  is  the  most  effective  form  of 
abbreviation  and  has  the  lowest  error  rate. 
Two  studies  of  automated  battlefield  informa¬ 
tion  systems  found  that  a  ,  our  letter  abbrevi¬ 
ation  had  the  lowest  error  rate  (Alderman, 
Ehrenreiih,  and  Rindewald,  I98'r;  Nvstrom  (* 
Givi  den  ,  1  978). 


letters  capitalized  to  indicate  the  abbreviated 
display  title. 

Screen  Formats 

One  function  of  the  CRT  will  be  to  assist 
the  operator  in  entering  messages  for  transmis¬ 
sion  to  another  warfare  command.  Fin-  t  >i!  swing 
recommendations  art*  ba  ed  on  extensive  findings 

by  Mace,  et.al.  (  1979.J.  I  tie  operator  shoul  i  be 
provided  with  p re  format,  t  ed  displays  mar.hinc 
all  message  formats.  Each  format  should  con¬ 
tain  all  standard  words  with  blank  spa-.  es  t  >r 
entry  of  required  information.  Ea-.  h  blank  space 
should  contain  codes  (l  -  Utter,  n  -  number) 
tor  tin*  legal  entries  in  each  space.  The  actu¬ 
al  letter-*  and  numbers  will  replace  the  code 
letters  as  they  art*  entered.  The  units  ot  mea¬ 
sure  (e.g.,  nnOUl)  yds)  should  appear  after 

the  blank  field.  The  cursor  should  sequence  to 
the  next  blank  entry  field  after  the  previous 
field  has  been  completed  or  the  ENTER  key  is 
depressed.  The  operator  should  be  allowed  to 

review  and  edit  the  message  before  transmis¬ 
sion.  Although  messages  using  both  upper  and 

lower  case  letters  are  easier  to  read,  messages 
received  at  sea  are  all  upper  case.  Typing 
messages  in  all  upper  case  is  faster  and  is  the 
recommended  approach. 

E  r  ror-Hand I ing 

Since  humans  are  error-prone  and  computers 
require  error-free  input  data  to  work  properly, 
the  BGTT  trainer  must  have  extensive  error-han¬ 
dling  features  in  order  to  operate  smoothly 
with  the  inexperienced  user.  An  important 

requirement  in  error-handling  is  informing  the 
user  about  entry  item  error  and  how  the  error 
can  be  corrected  ( Shne  iderman ,  1980). 

During  entry  of  a  number  of  fields  on  one 
format  (e.g.,  arm  and  fuel  an  aircraft),  each 
field  should  be  checked  for  legal  entries  as  it 
is  entered.  The  immediate  error  message  allows 
the  user  to  correct  the  error  and  continue.  If 
the  trainer  cannot  check  entries  by  field,  then 
the  error  message  issued  after  all  of  the 
fields  have  been  entered  must  clearly  specify 
which  field  is  in  error,  preferably  by  high¬ 
lighting  the  field.  The  user  should  be  allowed 
to  correct  that  field  without  reentering  all 
other  fields. 

Error  terms  such  as  ILLEGAL  ENTRY  art1  o  f 
limited  value  to  the  user.  Error  messages  such 
as  TYPE  MISMATCH  and  OUT  OF  LIMITS  are  useful 
to  the  experienced  user  but  do  not  help  tile 
i  ilex  pe  r  i  enc  ed  user  correct  errors.  Field 
checking  routines  are  basically  a  series  of  IF 
statements  m  t  he  computer.  The  routine  should 
have  a  separate  error  message  tor  each  IF 
statement.  This  approach  will  a  1  1  ow  the 
trainer  to  disp  ay  specific  error  messages  that 
indicate  how  *  he  error  can  be  corrected  (e.g., 
NUMBERS  REQUIRED,  LETTERS  R^QUIKl-D,  NUMBER  T*V> 
LARGE  )  . 
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player  requests  the  position  ot  an  undetected 
enemy  submarine,  the  error  message  should  s.jv 
DATA  lTNAVA  I  LABLF.  V)  BIJ'K  FoRCKS. 

Ins t  rue  t  iona  i  Suppler  t  K eat  ures 

Instruct iona l  support  features  can  provide 
automated  computer  assistance  to  rout  iru* 
nontraining  activities  and  direct  training 
quality  support  instructional  activities. 
Instructor  tasks  which  are  quantifiable, 
consume  time  and  divert  .attention  away  t  r  >m 
students  should  be  automated.  The  automation 
of  such  tasks  will  free  the  instructors  t  > 
perform  necessary  and  relevant  tasks  t» 
facilitate  training.  A  variety  of  instruction¬ 
al  support  features  were  examined  tor  BUTT 
system  app l i cab i 1 i t y  leading  t>  recommenda¬ 
tions.  The  features  examined  were  demonstra¬ 
tion,  malfunction  simulation,  freeze,  hardcopy, 
record/ rerun/ rep l ay ,  store/ reset  current 

conditions,  remote  display,  automatic 

performance  me.isur«  nent  ,  file  flags,  game 
rates,  modification  ot  events  and  system 
alerts. 

Demons  t  rat  ion 

Demonstrations  are  used  primarily  to  pro¬ 
vide  standardized  instruction  of  complex  new 
material.  Demonstrations  can  provide  students 
with  familiarization  lo  sequential  events,  a 
performance  model,  commented  practice,  and  a 
permanent  record/playback,  and  can  be  used  to 
evaluate,  develop,  and  critique  proposed 
tactics  (Hick l in,  1980;  Link  Division,  1978; 
Semple,  Cotton,  &  Sullivan,  1981). 

The  demonstration  feature  could  assist  tlu* 
Be;  r  r  control  group  in  preparing  f  he  student  tor 
the  gaming  exercise,  learning  system  oper¬ 
ations,  and  evaluating  new  tic  tics.  However, 
as  a  primary  or  required  instructional  feature, 
full  demonstration  capabilities  are  not  neces¬ 
sary  since  learning  th.*  operation  of  omplex 
trainer  scenarios  is  not  the  training  objec¬ 
tive.  Preparation  of  full  iemonst rat  ions  can 
be  time-consuming  and  labor-intensive.  Since 
skills  in  trainer  proficiency  are  not  being 
taught,  other  features  recommended  in  t  h  l  ->  sec¬ 
tion  can  fulfill  any  demons  i  rat  ion  need  that 
might  arise. 

Mai  fund  i  on  S  i mu  1  a  t  |on 

Malfunctions  ^  an  he  inset t.d  i:it  ■>  t  he 
training  scenario  nut omat  i >  a l I v  or  manually. 
The  malfunction  feature  allow,  :  *tul  u  par¬ 
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the  trail  i  ig  scenario.  The  p!av*i  lea  ins 
ma  l  turn  t.  ioi-cotnpensaf  ing  skill*-  an'  !■-,  i  s  \  *n 
processes  transferable  t  ■>  actual  ii’ nations 
(Caro,  Poll!  maun  S  Is  lev,  19  79).  Setup].-, 
Vreuls,  and  Cotton  (  1  979)  lound  that  iiv-t  ru- 
tors  preferred  manual  lapahilil  ies  ovr 
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file  flags  and  annotations  for  players  and 
controllers  is  recommended  for  the  BGTT. 


Game  Rates 

An  important  instructional  feature  is  the 
capability  to  manipulate  the  rate  at  which  the 
game  is  played.  Instructors  can  set  the  ratio 
of  exercise  t  im^  to  real-time,  to  accelerate, 
decelerate,  or  suspend  the  game,  or  step-ahead 
without  the  intervening  steps.  During  initial 
exercise  stages,  the  game  may  be  played  at  an 
accelerated  rate  while  planned  actions  are 
being  implemented.  As  the  exercise  progresses 
and  rapid  decisions  are  required,  the  game  rate 
may  be  decelerated  to  achieve  training 
objectives.  If  a  long  period  of  time  needs  to 
be  covered  quickly,  controllers  can  step  the 
game  ahead  in  time.  During  this  time  step, 
they  may  or  may  not  want  to  pause  for  salient 
events  or  record  the  intervening  steps.  This 
feature  allows  tailoring  the  game  speed  to 
player  proficiency,  game  movements  or  actions, 
and  training  objectives.  It  is  recommended  for 
BGTT. 

Modification  of  Events 

Instructional  intervention  allows  the  con¬ 
trol  group  to  modify  automated  events.  Too 
much  usage  of  this  flexibility  will  negate  the 
standardization  benefits  of  automation. 
However,  not  allowing  the  control  group  any 
intervention  capabilities  is  likely  to  inhibit 
user  acceptance  of  the  system  and  make  it  more 
difficult  to  tailor  events  to  meet  objectives 
(Semple,  et.al.,  1979).  The  BGTT  system  should 
allow  the  controllers  to  override  the  system  to 
change,  delete,  delay,  or  suppress  events. 
Instructors  have  indicated  that  the  override 
capability  is  necessary  in  automated  systems 
(McCauley  and  Semple,  1980).  This  override 
capability  should  not  be  used  arbitrarily,  but 
should  be  based  on  training  and  instructional 
objectives  and  monitored  by  senior  personnel. 
For  example,  the  control  group  may  decide  to 
relinquish  neutrality  and  modify  player  actions 
to  facilitate  objectives.  The  ability  to 
modify  events  is  recommended  for  BGTT 
control lers . 

System  Alerts 

The  primary  'purpose  of  system  alerts  is  to 
notify  the  controller  of  problems  or  errors 
which  require  attention.  They  can  notify  the 
control  group  when  a  parameter  has  exceeded 
preestablished  criteria  by  auditory  and/or 
visual  means.  This  feature  frees  the  instruc¬ 
tor  from  the  tasks  of  continually  monitoring 
these  parameters.  The  BGTT  control  group  could 
benefit  from  maintenance  alerts  which  notify 
the  controller  of  a  malfunction  in  the  system. 
The  malfunction  may  or  may  not  be  critical 
enough  to  warrant  immediate  attention,  but  the 
controller  can  make  that  assessment.  Alerts 
which  notify  the  control  group  of  excessive 
message  format  errors,  "illegal”  information 
requests,  or  trainer  command  errors  by  players 
would  assist  the  controllers’  player-monitoring 
tasks.  Those  performance  parameters  which  are 
specifiable  for  the  APM  and  indicate  errors 


may  require  further  assistance  or  clarification 
to  the  player.  It  is  recommended  that  main¬ 
tenance  alerts  be  provided  for  BGTT,  as  well  as 
a  flexible  performance  parameter  alert 
capab i l i ty . 

SUMMARY  AND  RFXOMMF.N  DAT  IONS 

The  purpose  of  this  initial  human  engineer¬ 
ing  analysis  was  to  examine  the  BGTT's  training 
requirements  and  objectives,  then  to  provide 
comprehensive  recommendations  on  system  hard¬ 
ware,  software,  and  instructional  support 
features.  The  analysis  was  based  on  an  exten¬ 
sive  review  of  the  BGTT  documentation  and  human 
engineering  literature,  site  visits  to  represen¬ 
tative  Naval  user  commands,  and  interviews  with 
Fleet  personnel  and  SMEs.  The  recommendations 
resulting  from  the  analysis  are  summarized 
be l ow . 

(1)  Provide  means  for  player  access  and 
output  of  the  information  specified 
in  the  requirement  tables. 

(2)  Provide  means  for  control  group 
access  and  output  of  the  information 
specified  in  the  requirement  tables. 

(3)  Provide  the  following  hardware  at 
each  player  station: 

o  An  Alphanumeric  Display 

o  A  Standard  ASCII  Keyboard  and 

Keypad 

o  A  Graphics  Display  with  Touch 

Screen 

o  An  Alphanumer ic  Printer 

o  A  Game  Book 

o  A  Secure  Telephone 

o  A  Work  Surface  for  Maps  and 

Hardcopy 

o  Facilities  for  Storing  and 

Retrieving  Hardcopy 
o  Chairs  for  Players 

(4)  Provide  the  following  additional 
hardware  at  each  control  group 
s tat  ion. 

o  One  Graphics  Printer  for  the 

Control  Group 

o  Access  to  a  Word  Processing 

System 

o  Access  to  an  Overhead  Projector 

and  Screen,  and  Viewgraph 
Production  Means 

(5)  Provide  a  12-inch  (or  larger)  diag¬ 
onal  standard  resolution  monochromat¬ 
ic  CRT  as  the  alphanumeric  display 
for  the  player  and  controller 
s  tat  ions . 

(6)  Design  a1  phanumer  ics  on  the  CRT  per 
MIL-STD-1472C  for  a  36-inch  viewing 
distance. 

(7)  Design  all  work  surfaces  for  sit- 
stand  operations  per  MIL-STD-1472C. 

(8)  Provide  a  touch  screen  (using  a  light 
bezel)  as  the  primary  means  of  player 
interaction  with  the  CRT,  as  well  as 
a  training  aid  for  operations  and 
control lers . 

(9)  Provide  a  high  resolution  (1024  lines 
or  equivalent)  21-inch  color  display 
as  the  graphical  display,  with  color 
and  shape  coding  of  symbols  (NTDS 
symbols  for  players).  To  locate  and 
identify  targets  and  platforms  on  the 


display,  a  light  pen  or  trackball  is 
recommended,  A  keypad  is  appropriate 
for  selection  of  optional  display 
functions  and  simple  interac t ions , 
while  a  standard  ASCII  keyboard  is 
recommended  for  more  complex  inter¬ 
interactions  by  the  operator. 

(10)  Provide  a  180  CPS  dot  matrix  printer 
with  sound  baffle  and  dual  tractor 
feed  and  capabilities  for  upper  and 
tower  case  letters,  bold  face  and 
underlining  for  the  warfare  command 
stations  and  control  group  stations. 

(11)  Provide  for  tabular  output  of  force 
capabilities,  resource  status,  cur¬ 
rent  policies  and  orders,  or  other 
quantifiable  data  for  inclusion  in 
the  Game  Book. 

(12)  Provide  the  control  group  access  to  a 
word  processing  system  with  storage 
files  of  Game  Book  data  not  available 
in  the  exercise  data  base.  This  word 
processor  should  be  a  standard 
commercially  available  system,  utiliz¬ 
ing  hard  or  floppy  disks  for  file 
storage.  A  medium  speed  (100  CPS) 
daisywheel  printer  is  recommended  for 
the  printing  quality  needed  in  the 
Game  Book. 

(13)  Design  the  software  such  that: 

(a)  The  raan-raach ine  interface  will 
be  computer-initiated  or  user- 
initiated  dialogue  at  user 
(player,  operator,  control 
group)  option.  tn  computer- 
initiated  dialogue,  the  system 
will  prompt  the  user  with  op¬ 
tions  on  a  menu,  and  the  user 
will  select  options  by  touching 
the  CRT  screen.  In  user-initia¬ 
ted  dialogue,  the  user  will  type 
an  abbreviated  title  of  the 
desired  display  on  the  keyboard 
or  keypad. 

(b)  Menus  of  options  list  the  names 
of  the  displays,  and  the  first 
four  letters  of  the  names  are 
capitalized  to  indicate  the 
abbreviated  title  of  the 
display. 

(c)  Provide  preformatted  displays  to 
operators  for  each  message 
between  warfare  commands  and  to 
the  control  group  for  task 
preparation.  The  formats  should 
contain  blanks  where  the  informa¬ 
tion  is  to  be  inserted  and 
provide  indications  of  legal 
entries  and  units  of  measure. 
The  cursor  should  sequence  to 
the  next  blank  field  after  each 
complete  entry.  All  messages 
should  be  all  upper  case 
letters . 

(d)  Provide  rapid  input  field  error¬ 
checking  routines  that  clearly 
indicate  to  the  user  the  input 
field  in  error  and  means  for 
correcting  it  without  having  to 
re-enter  information  in  other 
input  fields.  Legal  entries  for 
each  field  should  be  available 


at  user  command.  Reasons  for 
unavailable  information  should 
be  clearly  stated. 

(14)  Provide  the  following  ins t rue t  iona  1 
support  features : 

o  Automatic  Malfunction  Insertion 

with  Manual  Override 
o  Automatic,  Manual,  and  Snapshot 

F  reeze 

o  Alphanumeric  Hardcopy 

o  Graphic  Hardcopy 

o  Record/Rerun/Repl ay 

o  Remote  Display 

o  Modified  Automatic  Performance 

Measures 

o  File  Flags  and  Annotations 

o  Game  Rate  Control 

o  Event  Modification 

o  System  Alerts 
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ABSTRACT 


Training  Assistance  Technology  is  the  collection  of  tools  that  are  provided  as  part  of  the 
training  system  to  assist  the  instructor  in  conducting  the  training  process.  They  would 
typically  consist  of  automated  capabilities  designed  to  support  specific  Darts  of  the  training 
process,  such  as  to  provide  detailed  postscenario  feedback  to  the  trainees.  Many  of  these 
capabilities  would  be  implemented  as  a  part  of  the  computer-driven  training  device,  although 
usually  not  impacting  the  simulation  fidelity,  and  thus  comprising  the  training  subsystem  of 
the  training  device.  The  Submarine  Advanced  Reactive  Tactical  Training  System  (SMARTTS),  the 
direct  product  of  a  long-term  research  and  development  program  sponsored  by  the  U.S.  Naval 
Training  Equipment  Center,  is  the  initial  preprototype  implementation  of  Training  Assistance 
Technology  in  an  applied  environment.  SMARTTS  is  provided,  as  integrated  with  a  Submarine 
Combat  Systems  Trainer.  Other  applications  of  this  generic  technology  are  presented,  with 
detailed  examples. 


INTRODUCTION 

The  Submarine  Advanced  Reactive  Tactical 
Training  System  (SMARTTS)  has  been  developed  as 
the  "training  subsystem"  of  the  Submarine  Combat 
System  Trainer  (SCST),  the  primary  training 
device  employed  to  achieve  submarine  crew 
tactical  proficiency  (SMARTTS  Final  Report, 
Hamnell,  1983)'  U.  The  purpose  of  the 
preprototype  SMARTTS  was  to  implement  a  variety 
of  Training  Assistance  Technology  (TAT) 
capabilities  which  have  been  identified  on  the 
basis  of  laboratory  research  as  having  the 
potential  for  greatly  increasing  the 
effectiveness  of  simulator-based  training 
systems  (e.g.,  Hammell,  Manning,  and  Ewalt, 
1979) '2).  TAT  capabilities  support  the 
instructor,  trainee,  and  system  management;  they 
are  generic  in  that  they  are  relevant  to  every 
training  process.  These  capabilities  are  an 
addition  to  the  typically  provided  simulation 
capabilities  (e.g.,  target,  ownship,  environment 
simulation).  The  specific  subset  of  TAT 
capabilities  implemented  in  the  SMARTTS 
preprototype  at  the  Fleet  ASW  Training  Center, 
Norfolk,  Virginia  are  tailored  to  address 
individual  operator  and  combat  team  training 
requirements  associated  with  the  SSN  MK117  fire 
control  system.  The  capabilities  of  SMARTTS, 
however,  in  the  form  of  TAT,  are  generic  and 
generally  applicable  to  most  training  devices. 

TAT  Background 

An  instructor  station  has  traditionally  been  a 
part  of  every  simulator/training  device. 
However,  it  has  often  been  a  misnomer  consisting 
of  little  more  than  an  operator  station  for  the 
controlling  of  the  sophisticated  simulator. 
Relatively  few  capabilities  to  enhance  the 
Instructional  process  have  typically  been 
provided  as  part  of  the  instructor  station.  The 
necessary  technology  has  existed,  both  in  the 
form  of  hardware/software  capabilities  and 
training/instructional  techniques,  for  the 
development  of  highly  cost-effective  training 
tools  integrated  into  the  training  device  to 
enhance  the  instructional  process.  Thus,  a 
bonaflde  training  subsystem  embodieing  TAT 
capabilities  can,  and  should,  be  a  part  of  every 


training  device.  The  extent  to  which  these 
capabilities  should  be  implemented,  of  course, 
depends  upon  the  particular  training  system  and 
training  situation.  The  General  Accounting 
Office  in  their  report  to  Congress  concerning 
"How  to  Improve  the  Effectiveness  of  U.S.  Forces 
through  Improved  Weapon  System  Design"  ( 1  y8 1 ) 
focused  on  the  importance  of  the  operator  to  the 
overall  effective  functioning  of  the  weapon 
system.  They  estimated  that  human  errors 
account  for  at  least  50  percent  of  the  failures 
of  major  weapon  systems.  Several  of  their 
findings  point  to  the  obvious  need  to  design  the 
training  system  with  particular  regard  for  the 
instructor  and  trainee  interfaces.  This  is 
precisely  the  thrust  of  TAT,  and  the  SMARTTS 
preprototype. 

The  problem  of  developing  a  more  effective 
training  system  is  not  really  new,  since  the 
training  community  has  always  been  concerned 
with  the  effectiveness  of  instruction.  The 
predominant  emphasis  in  the  design  of  training 
devices  and  systems  in  recent  years,  however, 
has  been  placed  on  the  engineering  aspects,  such 
as  concern  over  adequate  simulation  fidelity  and 
the  technology  to  achieve  that  fidelity. 
Research  has  shown  that  the  instructor  can  have 
a  substantially  greater  impact  on  the 
effectiveness  of  the  training  system  than  major 
differences  in  simulator  fidelity  (Hammell, 
Gynther,  Grasso,  and  Gaffney,  1981)1^).  The 
importance  of  this  finding  is  that  it  strongly 
suggests  that  many  non-simulation  aspects  of  the 
training  device/training  system  (e.g.,  exercise 
design,  monitoring  of  student  performance, 
student  feedback)  are  extremely  important  to  the 
effectiveness  of  the  training  process.  TAT 
encompasses  capabilities  to  directly  support 
these  essential  aspects  of  the  training 
process.  The  training  device,  therefore  should 
be  more  than  just  a  simulator!  If  should 
provide  computer-based  capabilities  to  directly 
support  the  instructor  and  trainee  interfaces, 
and  hence  directly  support  the  training  process. 

The  advanced  training  concepts  embodied  in  TAT, 
and  those  included  as  a  subset  in  SMARTTS, 
directly  stem  from  two  studies  sponsored  by  the 
Naval  Training  Equipment  Center  (Hammell,  Sroka, 


and  Allen,  1971 ;(4)  Hammell,  Gasteyer,  and 
Pesch,  1973)(5'.  These  studies  investigated 
the  then-current  and  future  needs  of  submarine 
tactics  training  devices.  A  variety  of 
recommendations  were  forthcoming,  addressing 
individual  and  team  training  needs  at  basic  to 
advanced  levels;  and  new  training  devices,  as 
well  as  modifications  to  existing  training 
devices.  The  SMARTTS  preprototype  operating 
today  is  largely  a  subset  of  the  TAT 
capabilities  that  were  recommended  as  part  of 
these  earlier  investigations,  and  as  refined  and 
tailored  to  the  specific  application  of  the 
preprototype. 


The  need  for  TAT  capabilities  to  support  the 
complex  submarine  tactics  training  process  was 
readily  evident  upon  investigation.  Several 
subsequent  efforts  investigated  laboratory 
prototypes  of  TAT  (e.g.,  Hammell,  Manning,  and 
Ewalt,  1979),  finding  that  this  type  of 
technology  would  indeed  substantially  enhance 
the  tactics  training  process.  Cal lan,  Kelly  and 
Nicotra  (1978)'®)  implemented  several  of  the 
recommended  TAT  capabilities  on  the  21A40  SCST 
in  San  Diego  for  evaluation  in  an  applied 
training  setting.  Their  results  verified  the 
potential  of  TAT  capabilities  to  make  a 
substantial  contribution  to  submarine  tactics 
training.  The  SMARTTS  program  emerged  as  a 
result  of  a  series  of  investigations  indicating 
the  potential  for  substantial  training 
effectiveness  gains  to  result  from  TAT,  the 
ready  availability  of  hardware/software  to 
achieve  the  TAT  capabilities,  and  the  support 
shown  by  the  submarine  tactics  training 
community. 


SMARTTS  Description 


The  SMARTTS  preprototype  is  a  strap -on  subsystem 
designed  to  support  the  tactics  training  process 
associated  with  the  MK117  fire  control  system  of 
the  SSN  688  class  fast  attack  submarine. 
SMARTTS  can  operate  in  direct  support  closely 
integrated  with  the  already  existing  SCST 
simulation  system,  or  as  a  standalone  subsystem 
in  the  attack  center  and/or  the  adjoining 
classroom.  The  SMARTTS  instructor  and 


information  and  for  effecting  entry  commands  by 
the  instructor.  typically,  the  instructor  »ould 
enter  a  command  by  simply  pointing  to  tin- 
appropriate  English  language-text  choice  on  tin- 
plasma  display.  An  additional  interface  device 
in  the  attack  center  is  the  student  entry  flag. 
The  five  student  entry  flags  can  be  readily 
located  in  different  positions  around  the  attack 
center,  enabling  the  trainees  to  indicate  points 
in  the  scenario  that  they  wish  to  make  a  note  by 
simply  pressing  an  entry  flag  button.  This  flag 
is  automatically  recorded  in  the  scenario,  anu 
can  be  used  as  a  cue  during  the  postproblec 
briefing  session.  The  instructor  has  a  similar 
entry  flag  located  at  the  instructor's  console, 
also  for  similar  purposes. 

The  classroom  large  screen  display  presents 
information  similar  to  that  presented  on  the 
attack  center  overhead  displays.  The  control  of 
information  on  the  large  screen  display  is 
effected  via  the  instructor's  console  in  the 
classroom.  The  classroom  display  ana  instructor 
console  are  typically  used  for  preexercise  ano 
postexercise  scenario  briefings,  and  also  for 
classroom  standalone  purposes. 

SMARTTS  has  four  major  functions: 

1.  Simulation  Control  --  this  provides 
capabilities  for  scenario  generation  and 
problem  control  (i.e.,  control  of  the 
21A41  SCST  scenario  in  the  attack  center, 
or  control  of  problems  run  standalone 
under  SMARTTS  in  either  the  attack  center 
or  classroom) . 

2.  Data  Generation  --  performance 
indicators,  environmental  and  platform 
models  (i.e.,  used  primarily  during 
alternative  tactics  sessions),  and  the 
automatic  interactive  target  (AIT). 

3.  Data  Collection  and  Analysis  --  recording 
of  performance  indicators  and  other 
relevant  information,  data  management  and 
performance  information  analysis  and 
feedback. 


student/trainee  interfaces  (Figure  1)  consist  of 
(1)  two  overhead  displays,  an  instructor 
console,  and  a  student  entry  flag  unit  in  the 
attack  center;  and  (2)  a  large  screen  display 
and  an  instructor's  console  in  the  classroom. 
The  attack  center  overhead  displays  are  used  for 
presentation  of  info’rmation  to  the  fire  control 
party  prior  to,  during,  or  immediately  following 
the  exercise  scenario.  The  instructors  console 
is  the  primary  command  device  in  SMARTTS,  and 
also  the  major  information  presentation  medium 
for  the  instructor.  The  instructor,  using  this 
console,  can  set-up,  initialize  and  control  the 
scenario  in  the  attack  center.  He  can  monitor 
the  variety  of  tactically  relevant  parameters 
that  occur  throughout  the  scenario,  as  well  as 
specific  aspects  of  individual  and  team 
performance.  Subjective  observations  made  by 
the  Instructor  can  be  entered  via  this  console. 
Finally,  information  to  be  presented  to  the 
students  on  the  overhead  displays  is  controlled 
from  this  console.  The  instructor's  console 
Includes  an  upper  color-graphic  CRT  used  for 
presentation  of  information  and  a  lower 
touch-sensitive  plasma  panel  for  presentation  of 


4.  Trainee  Interactions  --  scenario  playback 
and  evaluation,  alternative  tactics 
analysis,  and  display  generation  and 
control . 

The  SMARTTS  processing  capabilities  are 

extensive  and  extremely  flexible,  allowing  for  a 
wide  range  of  operations.  For  example,  the 

scenario  generation  and  control  subfunctions  can 
be  used  off-line  by  the  instructor  to  develop 
and  generate  a  complex  scenario.  The 

subfunctions  would  then  also  be  used  to 
automatical ly  control  the  scenario  while  it  is 
in  progress.  Alternatively,  the  instructor 
could  interrupt  this  automatic  control,  and  take 
over  manual  control  of  the  scenario  while  in 
progress. 

The  essence  of  SMARTTS  is  its  capability  to 
collect  and  generate  a  variety  of  information 
pertinent  to  the  tactical  training  problem;  to 
display  various  combinations  of  that  information 
on  the  instructor's  console,  classroom  large 
screen  display  and  the  attack  center  overhead 
monitors,  at  appropriate  times  during  the 
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Figure  1.  SMARTTS  Instructor  ano  Trainee  Interfaces 


training  process;  and  to  dissect  and  analyze 
details  of  the  tactical  problem  (e.g.,  detailed 
aspects  of  trainee  performance,  relationships 
between  tactical  parameters  of  interest,  and  so 
on) . 

It  should  be  noted  that  SMARTTS  addresses  many 
aspects  of  the  total  training  system,  in 
addition  to  those  that  are  implemented  via  the 
computer-based  simulator/training  device.  The 
submarine  officer  tactics  training  process 
itself  has  been  modified  to  some  extent  under 
SMARTTS.  For  example,  SMARTTS  emphasizes  the 
conduct  of  a  prebriefing  prior  to  beginning  the 
attack  center  exercise  scenario.  The  various 
SMARTTS  capabilities  support  the  conduct  of  this 
prebriefing  in  the  classroom  or  in  the  attack 
center,  presenting  various  information  to  the 
students  on  the  SMARTTS  information  displays 
under  control  of  the  instructor.  Another 
example  is  the  instructor's  course  provided  as  a 
part  of  SMARTTS.  This  course  is  in  addition  to 
the  normally  provided  operator's  course,  which 
instructs  how  to  operate  SMARTTS.  The 
instructor's  course  focuses  on  the  use  of  the 
SMARTTS  capabilities  to  improve  the 
effectiveness  of  the  training  process.  Various 
instructor  support  materials  (e.g.,  instructor 
handbook)  have  also  been  provided  with  SMARTTS. 
The  SMARTTS  capabilities  presented  in  this  paper 
are  those  which  are  typically  Implemented  via 


automated  or  semi -automated  means  .vitn  the 
assistance  of  computer  processing.  Although 
these  represent  a  substantial  part  of  SMARTTS, 
and  that  which  is  most  visible  to  the  observer, 
other  major  aspects  of  the  training  system  have 
also  been  addressed. 


SMARTTS  CHARACTERISTICS 

The  three  major  aspects  of  SMARTTS  are  shown  in 
Figure  2.  The  major  hardware  has  been  addressed 
above.  In  addition,  several  off-line  terminals 
are  also  available  under  SMARTTS  for  generating 
exercises,  modifying  software,  and  so  on.  The 
major  modes  of  SMARTTS  operation  are  preview, 
run;  and  playback.  They  provide  for  support  of 
an  integrated  training  process  --  preview 
discussion  prior  to  actually  running  an  exercise 
in  the  attack  center;  monitoring  and  control 
during  the  actual  conduct  of  the  exercise 

scenario  in  real-time  in  the  attack  center;  and 
for  the  debrief /playback  that  occurs  immediately 
following  completion  of  the  attack  center 

exercise  scenario.  Other  inodes  of  SMARTTS 

operation  are  also  possible,  including 
standalone  operation  in  the  classroom  and 

off-line  exercise  generation  by  the  instructor. 

A  variety  of  training-related  capabilities  are  a 
part  of  SMARTTS,  with  the  major  capabilities 
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Figure  2.  Major  Aspects  of  SMARTTS 


listed  in  Figure  2.  Additional  capabilities 
exist  that  support  the  training  process  itself, 
as  well  as  off-line  functions  (e.g.,  exercise 
development).  Each  of  the  capabilities  listed 
in  this  figure  are  described  briefly  below. 

A  set  of  generic  capabilities  are  resident  in 
SMARTTS,  in  addition  to  those  addressed  below, 
that  permit  its  functioning  as  a  sophisticated 
training  aid.  These  are  implemented  via 
software  routines,  and  are  critical  to  the 
effective  functioning  of  SMARTTS.  They  include 
the  capabilities  of  data  collection,  storage, 
retrieval,  manipu^tion  and  analysis.  Most  of 
the  SMARTTS  capabilities  that  are  described 
below  rely  on  the  system's  ability  to  collect 
information  from  the  simulation  computer  and  the 
MK117  fire  control  system,  to  process  that 
information  for  data  storage  and/or  information 
presentation,  and  to  retrieve  that  information 
to  configure  the  necessary  display  formats  for 
presentation  to  the  students. 

Instructor's  Console 

The  Instructor's  console  is  the  main  interactive 
control  device  in  SMARTTS.  The  stand-up  console 
consists  of  an  upper  13  inch  color  graphic  CRT 
that  presents  information  to  the  instructor. 
The  lower  touch-sensitive  plasma  display  is  used 


as  the  entry  device.  This  console  is  used  by 
the  instructor  to  (1)  select  and  set-up  exercise 
scenarios  both  in  the  classroom  and  in  the 
attack  center;  (2)  modify  the  scenario  prior  to 
running,  and  store  the  modified  set-up 
parameters  if  so  desired  as  an  additional 
scenario;  (3)  monitor  details  of  the  ongoing 
exercise,  student  activities,  and  student 
performance;  (4)  receive  cues  automatically  from 
the  system;  (5)  control  the  scenario  (e.g., 
target  actions);  (6)  enter  and  store  subjective 
observations;  (7)  configure  and  control  display 
information  to  be  visually  presented  to  the 
students  in  the  classroom  and  attack  center;  and 
(8)  manipulate  information  on  the  displays  as 
appropriate  (e.g.,  alternative  actions). 

A  unique  capability  of  the  instructor's  console 
is  the  plasma  entry  device,  which  is  a 
touch-sensitive  display.  The  typical  instructor 
is  an  individual  with  an  extensive  operational 
background,  who  may  have  some  background  with 
computers.  Nevertheless,  his  previous 
experience  did  not  typically  include 
programming.  To  operate  a  sophisticated 
trainer,  however,  he  is  often  required  to  learn 
an  extensive  set  of  entry  commands,  formats,  and 
so  on.  The  plasma  entry  device  on  SMARTTS 
substantially  reduces  the  need  for  this  type  of 
learning  by  the  instructor.  It  presents  limited 
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sets  of  possible  instructor  entry  commands  on 
the  plasma  display  at  the  appropriate  point  in 
time,  typically  up  to  8  command  choices,  using 
readily  understandable  English-like  text.  The 
presentation  of  command  choices  on  the  plasma  is 
highly  structured  in  accordance  with  the 
operations  being  performed  by  the  instructor. 
This  type  of  an  interface  has  been  found  to 
reduce  the  instructor's  load  and  greatly 

facilitate  his  learning  of  the  system 
operation.  The  plasma  entry  device  is  one  of 
the  best  liked  features  of  SMART  TS.  The 

particular  sequence  of  plasma  formats/entry 
command  choices  can  and  should  be  continually 
modified  to  further  improve  the  instructor's 
operating  effectiveness.  The  plasma  interface 
allows  this  type  of  evolutionary  modification  to 
continuously  improve  the  system's  effectiveness. 

Performance  Indicators  and  Tactical  Variables 

The  performance  indicators  (PI)  and  the  tactical 

variables  (TV)  comprise  the  main  body  of 

information  relevant  to  specific  aspects  of 
individual  and  team  tactical  performance.  The 
Pi's  are  generated  from  TVs.  The  Pis  and  TVs 
are  collected,  stored,  manipulated,  and 
presented  via  the  information  displays.  They 
constitute  the  trainee  guidance  and  feedback 
information  critical  during  the  training  process. 

The  TVs  are  specific  parameters  collected  from 
either  the  simulation  computer  or  the  MK117  fire 
control  system.  They  provide  information 
relevant  to  specific  aspects  of  the  tactical 
situation.  Examples  include: 

target  range 

sonar  signal  to  noise  ratio 
-  time  of  target  zig 

The  two  types  of  Pis  are  (1)  objective  Pi's 
which  are  automatically  calculated  by  the 
computer,  and  (2)  subjective  Pi's  which  are 
manually  evaluated  by  the  instructor  and  entered 
into  the  SMARTTS  system  via  the  instructors 
console.  The  objective  PI  algorithms  use  the 
TVs  and  other  data  which  are  normally  generated 
throughout  any  trainer  exercise.  Many  of  the 
objective  Pis  are  calculated  continuously  and 
available  for  display  at  any  time  during  the 
exercise  or  following  completion  of  the 
exercise,  in  graphical  format  on  the  instructors 
console  or  on  an  information  display  in  the 
attack  center  and/or  classroom.  Examples  of 
objective  Pis  are: 

probability  of  counterdetection 

system  solution  range  accuracy 

periscope  exposure  time 

The  subjective  Pis  address  aspects  of 
performance  that  cannot  be  readily  calculated  by 
automated  means,  but  are  of  vital  importance  to 
the  training  objectives.  Occasionally,  a  cue  or 
an  alert  is  provided  to  the  instructor  via  the 
instructor's  console  to  indicate  a  particular 
occurrence  in  the  problem,  after  which  the 
Instructor  may  wish  to  enter  a  subjective  PI 
evaluation.  When  the  instructor  makes  a 
subjective  PI  observation  he  can  enter  his 
evaluation  into  SMARTTS  by  indicating  the 
appropriate  choice  on  the  plasma  entry  device. 
Similar  to  that  of  the  objective  Pis,  the 


recorded  subjective  Pis  can  be  displayed  during 
or  following  an  ext-rcist’  upon  command  of  the 
instructor.  Examples  of  subjective  Pis  are: 

initial  target  range  estimate 
periscope  observed  target  aspects 
fire  control  coordinator  effectiveness 

The  Pi's  and  TV's  comprise  the  information  that 
is  presented  to  the  students  via  the  attack, 
center  and  classroom  information  displays.  This 
information  pertains  to  overall  and  specific 
operations  of  the  fire  control  party  and 

individual  members.  The  information  is  used  to 
present  and  assess  sets  of  tactical  actions 
during  preview,  to  assess  the  student's 
performance  and  in  some  instances  provide 
information  during  the  real-time  exercise 
scenario  in  the  attack  center,  and  to  provide 
the  student  with  feedback  information  after 
completion  of  the  exercise  scenario.  These 
parameters  are  also  used  via  the  information 

displays  to  evaluate  the  impact  of  alternative 
tactical  actions  (i.e.,  see  alternative  tactics 
below) . 

Information  Displays 

Much  of  the  work  performed  by  SMARTTS  is  the 
collection  of  data  from  various  sources;  the 
transformation  of  that  data  into  meaningful 
tactical  variables  and  performance  indicators; 
and  the  presentation  of  relevant  information  on 
displays  to  the  instructor  and  trainees.  The 
information  presented  to  the  instructor  directly 
supports  his  functions  of  exercise  development, 
monitoring  and  control  of  training  and  control 
of  information  presentation  to  the  trainees. 
The  information  presented  to  the  trainees  on 
either  the  overhead  displays  in  the  attack 
center  or  the  large  screen  display  in  the 
classroom  is  primarily  used  to  summarize, 
dissect  and  investigate  particular  aspects  of 
tactical  problems;  to  provide  status  information 
concerning  the  particular  exercise  run  on  the 
training  device;  and  to  provide  feedback 
information  concerning  the  myriad  of  details 
regarding  the  tactical  performance  that  occurred 
during  the  exercise.  Four  classes  of  display 
formats  are  used  in  SMARTTS: 

1.  Alphanumeric  status  information 
tabular  listing  of  TV's  and  Pi's. 

2.  Geographical  plot  --  a  geographical  plot 

of  ownship  and  other  vessels,  including 
their  history  tracks.  This  display 
format  is  usually  combined  with  other 
alphanumeric  and/or  graphical 

information,  both  sharing  a  common 
display  surface.  For  example,  a 
1  ine-of -sight  diagram  may  be  presented 
simultaneously  with  the  geographical  plot 
display  via  a  split-screen  presentation. 

3.  General  purpose  X-Y  plots  --  this  format 
(see  Figure  3)  presents  a  selected  PI  or 
TV  on  the  vertical  axis  versus  any  other 
PI  or  TV  on  the  horizontal  axis. 
Usually,  time  is  used  as  the  horizontal 
axis  parameter,  thus  presenting  a 
particular  parameter  over  the  time  of  the 
scenario.  Up  to  9  parameters  plotted 
over  time  can  be  presented  simultaneously 
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on  a  SMARTTS  information  display.  This 
format  is  extremely  useful  for  (1) 
identifying  events  as  they  occurred 
throughout  the  scenario;  (2)  presenting 
information  concerning  individual  and 
team  performance  throughout  the  exercise; 
(3)  presenting  cause  and  effect 
information  relating  Pis  and  TVs;  and  (4) 
determining  and  evaluating  the 
relationships  between  various  Pis  and 
TVs.  The  simplified  example  of  Figure  3 
shows  in  the  upper  graph  the  time-range 
plot  to  the  target  during  the  exercise;  a 
closing  range  was  achieved  through  most 
of  the  problem,  with  a  nearly  constant 
range  near  the  end.  The  Probability  of 
Counterdetection  (PCD)  PI  throughout  this 
problem  is  shown  in  the  middle  graph;  the 
peak  PCO  occurred  around  time  X. 
Furthermore,  the  relationship  between 
Range  and  PCO  can  be  seen  by  correlating 
these  two  curves,  with  PCO  increasing  as 
range  decreases.  However,  a  step 
decrease  in  PCD  can  be  seen  at  time  X, 
not  in  correspondence  with  range.  This 
step  change  was  due  to  a  decrease  in 
ownship  speed  at  time  X,  shown  on  the 
lower  graph,  which  achieved  that 
desirable  decrease  in  PCO.  This  example 
shows  the  type  of  discussion  that  would 
occur  in  the  classroom  immediately 
following  the  exercise  scenario,  using 
the  SMARTTS  capabilities. 

4.  Special  purpose  display  formats  --  these 
are  display  formats  designed  to  address  a 
particular  aspect  of  tactical  operations 
or  training.  They  are  designed  for 
particular  objectives  and  are  generally 
not  applicable  across  the  range  of 
training  applications.  An  example  is  a 
time-bearing  plot,  which  is  used  for 
evaluating  and  discussing  manual  plotting 
techniques. 

Alternative  Tactics 

Learning  by  example  has  been  traditionally 
accepted  as  an  effective  training  methodology. 
The  alternative  tactics  feature  of  SMARTTS 
provides  a  computer-based  capability  to  rapidly 
generate  and  investigate  alternative  example 
problems.  Prior  to  conducting  a  real-time 
exercise  on  the  training  device  the  instructor 
may  wish  to  explore,  particular  concepts  in  the 
classroom  (e.g.,  various  barrier  patrol  patterns 
to  intercept  a  transiting  submarine)  by 
illustrating  the  impact  of  various  ownship  or 
target  alternative  actions  on  the  performance 
indicators  of  interest.  This  would  provide  the 
trainees  with  an  understanding  of  the  trade-offs 
associated  with  the  range  of  actions  available 
to  them.  Similarly,  after  investigating  a 
previous  exercise  scenario  during  the  feedback 
session  the  instructor  may  wish  to  present 
ownship  and  target  action  alternatives  to  those 
that  actually  occurred  during  the  scenario,  so 
as  to  explore  the  possible  results  of 
alternative  sets  of  tactical  actions  in  contrast 
with  those  that  ownship  actually  did.  For 
example,  after  a  two-hour  exercise  during  which 
ownship  was  on  a  barrier  patrol  and  encountered 
a  transiting  enemy  submarine,  took  appropriate 
action  to  approach  and  attack,  and  eventually 


Figure  3.  Pi's  and  TV's  Presented 
as  Feedback  During  Debriefing 

completed  the  scenario,  the  instructor  may  wish 
to  illustrate  the  effectiveness  of  other  types 
of  approach  tactics  for  ownship  in  that 
particular  problem.  These  alternative  sets  of 
actions  may  be  equally  effective,  les. 
effective,  or  more  effective  than  those  which 
the  crew  actually  did.  From  a  training 
standpoint,  it  is  important  that  the  trainees 
understand  the  various  trade-offs  involved  with 
the  particular  actions  that  they  took  in 
comparison  with  the  other  available  actions. 
The  knowledge  gained  from  this  type  of  activity 
constitutes  learning. 

The  alternative  tactics  feature  is  also  of 
considerable  use  during  the  exercise  design 
process.  The  instructor  can  generate  and 
investigate  alternative  sets  of  ownship  and/or 
target  actions  while  constructing  a  particular 
scenario.  This  type  of  evaluation  will  enable 
him  to  more  rapidly  construct  a  valid  scenario. 
The  alternative  tactics  capability  includes  the 
following: 

•  Up  to  five  future  ownship  maneuver  legs 
can  be  projected 

•  Up  to  five  target  maneuver  legs  can  be 
projected 

•  Objective  Pis  and  TVs  are  rapidly 
calculated  during  the  projected  maneuvers 

•  Projection  times  can  range  from  1  to  120 
minutes 


186 


Instructor  Cues 

Cue  information  is  provided  to  the  instructor  in 
real-time  via  the  instructor  remote  console  in 
the  attack  center  during  an  exercise  scenario. 
Two  types  of  cues  are  provided  for  training 
purposes : 

1.  Notes  --  cues  embedded  in  the  script  of 

each  exercise  scenario,  such  that  they 
are  displayed  at  predetermined  times 
(e.g.,  list  of  training  objectives 

displayed  at  the  start  of  an  exercise). 

2.  Alerts  --  a  cue  provided  to  the 

instructor  on  the  basis  of  one  or  more 
events  having  occurred  during  the 

exercise.  The  time  at  which  the  alert  is 
issued  depends  upon  the  real-time 

occurrence  of  particular  events  in  the 
scenario.  For  example,  an  alert  may  be 
given  when  the  probability  of 

counterdetection  exceeds  a  predetermined 
value,  such  as  50  percent. 

Exercise  Library 

The  library  contains  a  set  of  exercises 
developed  to  support  a  variety  of  tactical 
training  objectives.  Each  exercise  can  be 
selected  and  automatically  initiated  on  the 
system.  This  automatic  initiation  greatly 
reduces  the  instructor's  workload  in  setting  up 
an  exercise.  Additionally,  various  aspects  of 
the  exercise  can  be  previewed  and  modified  by 
the  instructor  immediately  prior  to  automatic 
loading  on  the  trainer.  If  he  chooses  to  modify 
exercise  parameters  the  modified  exercise  can  be 
automatically  saved  if  so  desired,  and  added  to 
the  exercise  library. 

Automatic  Interactive  Target 


The  automatic  interactive  target  (AIT)  has  been 
included  in  SMARTTS  for  the  dual  purpose  of 
reducing  the  instructor's  workload,  and 
improving  the  target  simulation.  The  AIT  is  a 
computer  controlled  target  model,  driven  by  the 
decision  structure  of  an  enemy  submarine 
platform.  The  AIT  acts  as  an  intelligent 
adversary,  whose  ship  has  capabilities 
equivalent  to  those  of  the  actual  at-sea  enemy 
submarine  platform.  The  AIT  reacts  to  ownship 
actions  as  he  would  be  expected  to  receive 
information  through  the  environment  and 
intelligence  sources,  interpret  that  information 
and  select  his  tactical  actions.  The  AIT 
structure  is  based  on  a  dynamic  probabilistic 
decision  model,  with  three  levels  of  competency 
ranging  from  basically  capable  to  highly 
capable.  The  actions  available  to  the  AIT  and 
their  probabilities  of  occurrence  are  keyed  to 
the  AIT's  level  of  expertise  and  other  factors 
(e.g.,  operational  mission).  Examples  of  the 
major  maneuvering  sequences  available  to  the 
AIT,  of  which  alternative  sets  of  actions  will 
occur  on  a  probabilistic  basis,  are: 

transit  tracks 
patrol  search  patterns 
-  baffle  clearing  maneuvers 
approach  and  torpedo  attack 


Monitoring  and  control  capabi 1  it ies  are  provided 
to  the  instructor  for  overseeing  the  AIT 
actions.  Alerts  are  provided  on  the 
instructor's  console  in  the  attack  center 
informing  him  of  decisions  being  made  by  the  AIT 
and  impending  AIT  actions  prior  to  their  actual 
occurrence.  The  instructor  can  override  planned 
actions,  and  can  also  initiate  a  preset  pattern 
of  actions  (e.g.,  a  particular  baffle  clearing 
sequence).  These  AIT  capabilities  greatly 
reduce  the  amount  of  instructor  work  in 
controlling  the  target,  and  will  often  increase 
the  fidelity  of  target  actions. 


GENERIC  TRAINING  ASSISTANCE  TECHNOLOGY 

The  SMARTTS  preprototype  embodies  the  initial 
major  application  of  training  assistance 
technology  (TAT)  in  an  operational  training 
setting.  These  capabilities  are  generic  in  that 
they  are  applicable  to  many  computer-based 
training  systems.  The  particular  TAT 
capabilities  and  the  manner  in  which  they  should 
be  implemented  depends  on  the  particular 
training  system  and  training  situation. 
Nevertheless,  many  of  the  TAT  capabilities,  as 
exemplified  by  those  in  the  SMARTTS 
preprototype,  should  be  a  part  of  most  training 
systems.  Several  of  the  major  generic  TAT 
capabilities  are: 

•  Performance  indicators  (PI)  --  both 
objective  (automatical ly  calculated  by 
the  computer),  and  subjective  (observed 
by  the  instructor  and  manually  entered 
into  the  system). 

•  Relevant  situation  variables  (SV) 
(similar  to  SMARTTS  TV's) 
automatically  collected  and  recorded. 

•  Student  information  displays  --  such  as  a 

large  screen  display  in  the  classroom; 
used  for  presenting  a  variety  of 
information  to  the  students  (e.g., 
preexercise  briefing,  postexercise 

feedback;  performance  indicators, 

scenario  data). 

•  Instructor's  console  --  located  both  in 
the  classroom  and  in  the  relevant 
simulator  operations  area;  it  should 
provide  information  for  monitoring  the 
problem  status  and  student  performance; 
it  should  have  capabilities  to  control 
the  scenario,  and  to  control  information 
presentation  to  trainees  via  the  displays 
and  other  TAT  characteristics. 

•  Alternative  actions  (similar  to  SMARTTS 
alternative  tactics)  --  for  presenting 
fast-time  examples  in  the  classroom 
context;  this  learning-by-example 
technique  is  useful  for  investigating  a 
range  of  relevant  problems  and 
own-platform  actions  during  the  prebrief, 
and  for  diagnostically  investigating 
alternative  actions  during  the 
postbriefing. 
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TAT  capabilities  are  currently  operating  as  part 
of  at  least  one  training  device  in  an 
application  area  very  different  from  that  of 
SMARTTS  --  commercial  merchant  marine 
shiphandling  training  via  a  ship  bridge 
simulator.  Furthermore,  the  applicability  of 
TAT  characteristics  has  been  investigated  with 
regard  to  application  in  several  other  contexts, 
including  CIC  training  and  sonar  training.  The 
specifics  of  TAT  application  differ  for  each  of 
these  areas,  and  for  the  SMARTTS  preprototype. 
However,  the  generic  TAT  capabilities  remain  the 
same  in  each  application,  with  the  specifics 
tailored  to  the  particular  training  situation. 
The  application  of  TAT  capabilities  in  each  of 
these  three  areas  is  discussed  briefly  below. 

Shiphandling  Training 

Shiphandling  training  has  traditionally  been 
accomplished  at-sea,  for  both  military  and 
commercial  applications.  The  shiphandling/ship 
bridge  simulator,  or  training  device,  is  a 
relatively  recent  development.  Less  than  two 
dozen  such  training  devices  have  been  placed  in 
operation  over  the  past  15  years.  The 
commercial  merchant  marine  (i.e.,  including 
Maritime  Academy  Cadets,  deck  officers,  and 
harbor  pilots)  have  steadily  increased  their 
acceptance  of  training  via  the  training 
device/simulator  over  the  past  5  years  to  the 
point  that  these  devices  have  recently  become 
widely  acclaimed  as  a  cost-effective  means  for 
achieving  a  considerable  amount  of  shiphandling 
training. 

The  ship  bridge  training  device  consists  of  a 
general  bridge  area  containing  the  various 
instruments  and  controls  typically  found  on  the 
bridge  of  a  commercial  vessel  (e.g.,  internal 
and  external  communications  systems,  steering 
stand,  rudder  and  rpm  controls,  various 
navigation  electronics,  radar,  and  so  on).  The 
sophistication  and  complexity  of  the  bridge 
simulator  lies  in  the  large-scale  visual  scene 
that  is  a  necessary  part  of  this  training 
device.  Various  methods  have  been  used  to 
generate  an  appropriate  visual  scene.  As  a 
result,  the  simulators  worldwide  differ  greatly 
with  regard  to  their  visual  scene  capabilities 
(e.g.,  some  are  nighttime  only,  while  others 
present  both  daytime  and  nighttime  scenes;  some 
can  present  traffic  vessels  in  the  harbor  area, 
while  others  cannot).  Computer  generated 
imagery  is  becoming  a  stable  technology  for  the 
generation  of  the  visual  scene  for  this  type  of 
training  device. 

The  training  objectives  that  have  been  addressed 
on  ship  bridge  training  devices  encompass  a 
number  of  areas,  including  the  application  of 
navigation  principles,  emergency  maneuvering  of 
the  vessel,  maneuvering  under  conditions  of 
shallow  water  and  bank  effects,  communications 
within  and  between  ships,  bridge  team  work,  and 
collision  avoidance  maneuvering. 

The  Ship  Analytics'  ship  bridge  training  device, 
and  a  similar  unit  currently  being  installed  for 
the  Marine  Engineers  Benevolent  Association 
(i.e.,  a  maritime  trade  association)  have 
incorporated  a  variety  of  TAT  capabilities. 
These  include  performance  indicators,  situation 
variables,  student  information  displays,  and 


alternative  action  capabilities.  for  example, 
the  situation  variables  and  performance 
indicators  can  be  played  back  in  a  tanner 
similar  to  those  of  the  SMART  IS  pre-prototype 
(;.e.,  detailed  diagnostic  feedback).  A  variety 
of  commercial  organ i zat ions  and  U.S.  coast  Ouarj 
Cadets  and  officers  have  received  training  on 
this  device,  utilizing  the  TaT  capabilities. 
These  capabilities  are  generally  regarded  as  one 
of  the  unique  and  most  effective  aspects  of  this 
training  device.  Examples  of  TAT  use  are 
presented  in  Figures  4  and  5.  Figure  4  snows  a 
classroom  reconstruction  of  the  immediately 
preceding  exercise  (i.e.,  feedback  during 
debriefing).  This  reconstruction,  which  is 
automatically  presented  on  the  classroom  largo- 
screen  display,  shows  ownship  track  through  the 
exercise  (indicated  by  the  successive  line  of 
ownship  images),  and  those  of  other  contacts 
during  the  problem  (A  and  B).  The  primary 
contact  during  this  collision  avoidance  training 
exercise  (i.e.,  contact  A  indicated  by  the  black 
ship  images)  was  the  Give-Way  vessel,  required 
by  international  law  to  maneuver  to  avoid  the 
impending  collision.  Ownship  was  the  stand-on 
vessel  required  by  law  to  maintain  course  and 
speed  until  safely  passing  contact  A,  or  until 
it  becomes  apparent  that  contact  A  is  taking 
insufficient  action  to  safely  avoid  ownship, 
whereupon  ownship  must  take  action  to  avoia  a 
collision.  In  this  particular  exercise,  contact 
A  did  not  take  early  and  substantial  action,  and 
took  action  only  shortly  prior  to  a  collision 
with  ownship.  Ownship,  on  the  other  hand, 
prudently  executed  action  as  a  stand-on  vessel 
to  avoid  a  collision  after  it  was  apparent  that 
contact  A  was  not  acting  prudently.  However, 
although  not  prohibited  by  the  international 
rules-of-the-road  from  doing  so,  ownship 
maneuvered  to  port  rather  than  starboard. 
Contact  A  did  take  late  action,  and  also 
maneuvered  in  the  same  direction  as  ownship, 
thus  ultimately  creating  a  near  collision. 

The  postproblem  briefing  would  typically  play 
back  the  scenario  in  fast-time,  keying  on  the 
events  as  they  occurred  and  the  relevant 
information  (i.e.,  range  to  all  contacts, 
projected  time  of  collision  with  contact  A, 
ownship  maneuvering  options  available,  and  so 
on).  These  data  are  automatically  collected  on 
the  training  device  and  made  available  for 
presentation  throughout  the  postproblem 
briefing.  Range  to  the  various  contacts,  for 
example,  is  presented  on  the  feedback  display  of 
Figure  4,  corresponding  to  the  current  time,  and 
updated  accordingly  as  playback  occurs.  Hence, 
this  feedback  display  would  be  used  to  discuss 
the  scenario  that  was  just  completed  on  the 
simulator/training  device. 

The  focal  point  of  feedback  in  this  example 
would  obviously  be  the  selection  of  the  ownship 
maneuver  to  port,  rather  than  starboard.  As 
noted  above,  the  port  maneuver  is  not 
prohibited.  However,  the  rules-of-the-road 
suggest  a  maneuver  to  starboard,  because  of  the 
potential  of  a  late  give-way  vessel  maneuver  as 
occurred  in  this  particular  scenario.  The 
instructor  would  discuss  maneuvering  options 
available  to  ownship  as  the  stand-on  vessel, 
particularly  starboard  maneuvers.  Perhaps  the 
students  were  concerned  with  contact  B  which 
appears  to  present  a  maneuvering  constraint  to 
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Figure  4.  Collision  Avoidance  Scenario  Feedback  Display 
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the  starboard  side.  The  alternative  actions  TAT 
capability  would  be  used  at  this  time  to 
investigate  alternative  maneuvering  options 
available.  Figure  5  shows  one  such 
alternative.  The  alternatives  (i.e.,  ownship 
course  change  and  time  or  range  of  maneuver)  are 
entered  by  the  instructor,  rapidly  calculated  by 
the  computer  and  added  to  the  feedback  display 
as  shown  in  this  figure.  Appropriate 
performance  indicators  and  scenario  variables 
are  also  "generated  and  presented.  In  this 
example,  an  ownship  maneuver  of  about  35  degrees 
at  a  range  of  about  2  miles  from  contact  A  would 
have  resulted  in  an  acceptable  passing  distance 
with  contact  A,  whether  or  not  A  maneuvered;  and 
would  not  have  developed  into  a  close  situation 
with  contact  B.  Additional  maneuvering  options 
could  be  investigated  in  a  similar  manner. 

The  use  of  the  TAT  capabilities  enabled  the 
instructor  to  reconstruct  the  scenario  and 
present  a  detailed  playback  picture  of  the 
events  that  occurred,  and  to  conduct  an  in-depth 
discussion  of  the  student's  actions. 
Furthermore,  these  capabilities  enabled  the 
instructor  to  investigate  alternative  actions 
(i.e.,  learn-by-example)  across  the  appropriate 
range  of  potential  maneuvers  available,  and  thus 
provide  the  students  with  an  understanding  of 
the  range  of  options  available,  and  their  likely 
outcomes. 

Research  conducted  for  the  U. S.  Coast  Guard 
(Gynther,  1981 )(^)  has  shown  that  application 
of  these  TAT  capabilities  to  a  ship  bridge 
trainer  resulted  in  a  more  effective 
shiphandling  training  process.  Prior  to  this 
application  of  TAT,  ship  bridge  training  devices 
provided  relatively  little  capability  for 
instructional  support.  Other  of  the  TAT 
capabilities  are  also  resident  on  this  ship 
bridge  training  device. 

Sonar  Training 

The  skills  and  knowledge  required  to  function  as 
a  proficient  sonar  operator  and  sonar  team  are 
different  from  those  of  both  submarine  tactics 
and  shiphandling.  The  sonar  team  conducts  a 
constant  search  of  the  ocean  environment  relying 
on  both  active  and  passive  sonar  devices, 
studying  both  aural  and  visual  information. 
Upon  detecting  a  noise  source  that  might  be  a 
contact  of  interest,  classification  procedures 
begin  using  various  processing  devices,  again 
using  both  aural  and  visual  information.  After 
the  noise  source  has  been  classified  as  a 
contact  of  interest,  tracking  begins.  Tracking 
can  be  manual  with  one  or  more  sonar  operators 
manually  training  sonar  beams  on  the  contact  of 
interest  as  it  moves  through  the  environment,  or 
can  be  automatic  via  sophisticated  tracking 
devices.  Training  for  sonar  operators  and  the 
sonar  team  occurs  at-sea  using  the  actual  sonar 
equipment,  and  on  shore-based  -training 
facilities  using  sophisticated  sonar  training 
devices. 


information  displays  are  important  tools  tout 
can  be  used  by  the  sonar  instructor  to  enhance 
the  sonar  training  process.  Unce  again,  the 
automatic  collection  and  recording  of  these 
data,  and  having  them  available  for  presentation 
to  the  students  during  the  postbriefing  (i.e., 
as  feedback)  should  substantially  improve  the 
sonar  operator/student 's  understanding  of  the 
sonar  problem  and  his  performance. 

An  example  of  the  use  of  several  TA1 
capabilities  is  presented  in  Figure  b.  The 
ability  of  each  individual  sonar  system  to 
detect  a  contact  depends  on  the  particular 
characteristics  of  the  contact,  the  manner  in 
which  the  equipment  is  set-up,  and  other 
factors.  Assume  that  the  training  objective  in 
this  example  addressed  equipment  line-up.  The 
feedback  display  presented  in  Figure  6  would  be 
used  by  the  instructor  to  address  the  range  of 
coverage  actually  achieved  by  the  equipment 
line-up  used  during  the  immed iately  preceding 
scenario.  This  display  would  be  presented  in 
the  classroom  during  the  debrief.  The  area  of 
coverage  achieved  by  the  sonar  team  shown  on 
this  display  as  line-up  A.  A  360  degree  area  of 
coverage  around  ownship  was  achieved  out  to  a 
range  of  XX  yards.  At  the  outer  boundary  of 
this  area  a  50  percent  probability  of  detecting 
targets  of  interest  exist.  Targets  further 
inside  this  area  would  have  a  higher  probability 
of  detection.  The  areas  of  coverage  that  would 
be  achieved  with  alternative  equipment  line-ups 
are  also  included  on  this  feedback  display.  For 
line-up  B  (e.g.,  particular  filter  settings)  a 
360  degree  area  around  ownship  would  be  covered 
out  to  a  range  of  VY.  This  YY  sonar  range  is 
substantially  less  than  that  actually  achieved 
by  the  sonar  operator/students,  which  was  a 
range  of  XX  yards.  However,  equipment  line-up  C 
would  achieve  a  range  of  coverage  slightly 
greater  than  that  achieved  by  the  sonar 
operator,  (i.e.,  a  range  of  ll  yards). 

This  type  of  feedback  information  and 
investigative  capabilities  are  unavailable  in 
the  current  sonar  training  devices.  Although 
the  existing  trainers  are  excellent,  they  do  not 
have  the  added  training  assistance  technology 
capabilities  which  can  substantial ly  assist  the 
instructor  in  conducting  an  effective  training 
process.  The  very  simplistic  type  of 
information  presented  in  this  example  would  have 
to  be  presented  verbally  by  the  instructor,  and 
even  then  the  instructor  would  not  have  the 
capability  to  rapidly  determine  the  appropriate 
ranges  of  coverage.  This  initial  feedback 
display  showed  the  performance  achieved  by  the 
operator/trainees  during  the  problem  in  the  form 
of  visual  feedback.  The  alternative  actions 
capability  enabled  the  instructor  to  expand  that 
problem  and  address  the  line-up  options 
available  to  the  students,  and  their  likely 
outcomes.  This  would  help  to  both  reinforce 
appropriate  performance  by  the  operators,  and  to 
identify  and  help  overcome  areas  that  require 
improvement. 


Although  the  particular  skills  and  knowledge  are 
substantially  different  from  those  of  tactics 
training,  the  SMARTTS-type  generic  TAT 
capabilities  are  applicable.  For  example, 
capabilities  such  as  the  automatic  generation  of 
Pi's  and  SV's  and  their  presentation  on 


Surface  CIC 

The  SMARTTS-type  TAT  capabilities  have  been 
investigated  for  their  applicability  to  the 
training  of  surface  CIC  teams.  A  variety  of 
recommendations  for  the  incorporation  of  TAT 
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Figure  6.  Simplified  Hypothetical  Feedback  Display  For  Sonar  Training, 
Addressing  Equipment  Line-up 
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capabilities  was  forthcoming  from  this 
investigation  (Matter,  Hammell,  and  Shortall, 
1981)181.  The  types  of  generic  capabilities 
discussed  above  were  recortmended,  again  with  the 
specific  content  required  to  be  developed 
specifically  for  the  surface  CIC  problem. 

An  example  of  the  use  of  TAT  in  CIC  training 
addresses  the  unmasking  of  a  weapon  system  to 
engage  an  incoming  target.  Most  surface  vessels 
are  designed  such  that  certain  weapon  systems 
are  prevented  from  firing  in  certain  relative 
directions  since  the  ownship  super  structure 
(other  gun  mounts,  etc.)  would  interfere  with 
the  outgoing  ordnance.  Hence,  it  may  be 
important  to  unmask  a  particular  weapon  system 
prior  to  firing  at  the  target;  this  would 
involve  an  ownship  maneuver  to  position  the  ship 
to  enable  the  weapon  system  to  have  a  clear  shot 
at  the  target.  The  time  and  manner  in  which 
unmasking  should  occur  is  dependent  on  a  number 
of  factors  related  to  the  particular  problem 
situation.  Generally  speaking,  it  is  desirable 
to  unmask  the  weapon  system  as  soon  as  possible, 
thus  allowing  a  weapon  to  be  fired  at  the 
earliest  appropriate  time. 

An  example  of  a  feedback  display  pertaining  to 
weapon  unmasking  is  presented  in  Figure  7.  This 
would  be  used  in  a  manner  similar  to  the 
examples  presented  above,  during  the 
postbriefing  session  in  the  classroom.  The 
display  format  shows  the  range  of  radar  coverage 
of  ownship  along  with  the  areas  of  weapon  system 
masking  (i.e.,  shaded  areas  in  the  figure).  The 
incoming  target  position  and  track  is  shown  by 
the  series  of  T  symbols,  developed  in  fast-time 
during  playback.  The  target  was  detected  by 
ownship  radar  at  a  relative  bearing  on  which  the 
particular  weapon  system  was  masked  (see 
Detection  Column  in  figure).  As  the  problem 
develops  during  playback  the  operator  trainees 
can  see  the  track  of  the  target  as  well  as  the 
point  at  which  the  ownship  maneuver  unmasked  the 
weapon  system.  In  this  feedback  display  example 
the  instructor  could  investigate  target  range 
and  bearing  at  various  points  in  the  problem 
(i.e.,  current  time  is  indicated  by  T  on  the 
display,  with  appropriately  corresponding  data 
in  the  alphanumeric  table)  by  manually  stepping 
through  the  scenario  time  increments.  ftvnship 
maneuvered  to  unmask  the  particular  weapon 
system,  in  this  example,  and  achieved  unmasking 
at  time  "A",  with  a  corresponding  probability  of 
kill  of  “0".  Alternative  actions  could  be  used 
to  investigate  the  impact  of  earlier  or  later 
maneuvers,  or  different  types  of  maneuvers,  on 
relevant  Pi's  (i.e.,  such  as  the  probability  of 
kill). 

This  example  presents  the  application  of  TAT 
capabilities  specific  to  CIC  team  training, 
although  again  the  capabilities  themselves  are 
of  a  generic  type  (i.e.,  automated  performance 
indicators  and  information  feedback  displays). 
Their  applied  use  in  this  example  is  different 
from  those  presented  above,  although  the 
fundamental  elements  of  the  training  process  are 
similar  (e.g.,  visual  feedback).  The  particular 
application  of  the  TAT  capabilities  depends  on 
the  many  considerations  surrounding  the 
particular  training  application. 


SUMMARY 

The  common  thread  across  the  above  three 
examples  of  the  application  of  SMARTlS-type 
training  assistance  technology  has  focused  on 
the  postproblem  briefing  using  objective 
performance  indicators  that  have  been 
automatically  collected  and  presented  as 
feedback  to  the  trainees  via  a  classroom 
information  display.  Additionally,  in  several 
examples  an  alternative  actions  capability  was 
used  to  expand  the  investigation  to  the  various 
options  available  and  their  likely  outcomes. 
The  generic  capabilities  have  been  the  same  in 
each  of  the  examples,  although  the  specific 
content  differed  and  was  tailored  to  each.  The 
training  process,  of  course,  was  basically  the 
same  across  each  of  the  three  areas  investigated 
—  the  types  of  skills  and  knowledge  to  be 
trained  were  generally  of  a  cognitive 
decisionmaking  nature,  requiring  an  in-depth 
understanding  of  the  relationships  between  a 
variety  of  parameters,  and  their  trade-offs  in 
achieving  operational  goals. 

The  training  strategy  under  which  the  TAT 
capabilities  would  be  used,  may  differ 
substantially  for  each  training  application. 
For  example,  at  a  basic  level  of  training 
considerable  immediate  feedback  presenting  the 
automated  performance  indicators  on  feedback 
displays  in  the  operational  environment  itself 
may  be  desirable;  conversely,  at  intermediate 
and  advanced  levels  of  training  the  feedback 
should  be  delayed  and  presented  during  a 
postproblem  briefing. 

These  examples  demonstrate  how  instructor  and 
trainee  interface  capabilities  can  enhance  the 
training  process  when  added  to  the  simulation 
capabilities  of  training  devices. 
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ABSTRACT 

The  training  requirements  and  the  project  schedule  for  the  PGS  (Platoon  Gunnery  Simulator)  will 
be  presented  by  the  French  counterpart  of  the  PM  Trade.  Then  the  firm  under  contract  for  the  design 
and  manufacture  of  the  PGS  will  give  a  more  detailed  presentation  of  the  equipment,  emphasizing  the 
system  features  :  -  an  equipment  unique  in  its  kind,  providing  combat  training  in  a  classroom  for  the 
crews  of  a  platoon  of  tanks  -  total  compliance  with  ergonomic  aspects  -  extraordinary  detail  and 
realism  of  the  landscapes  into  which  are  inset  up  to  6  fixed  and/or  mobile  targets  -  consistent 
representation  of  all  the  effects  of  firing  (noise,  flash,  recoil,  observation  of  the  shell 
trajectory)  -  perfect  adaptation  to  each  type  of  turret  -  versatile  and  easy  to  use  for  the 
instructors. 

Two  simulators  are  to  be  delivered  to  the  French  Army  in  1984  -  1985. 


PGS  PROGRAM  DESCRIPTION 

In  1979,  the  French  Army  Staff 
Headquarters  issued  a  requirement  for  a 
training  device  providing  initial  training  and 
continuation  training  for  crews  of  AMX30-B, 
AMX30-B2  and  AMX10-RC  tanks. 

Objectives 

Classroom  training  and  instruction  for 
tank  crews  in  all  the  listed  combat  actions 
(observation  roles,  observation,  detection, 
reconnaissance,  identification,  allocation  of 
targets,  engagement  of  targets  by  main  gun 
with  appropriate  firing  sequence,  adjustment 
of  aim  for  second  shot).  These  objectives  need 
a  representative  (high  fidelity),  realistic 
and  high  performance  training  tool. 

1.  Who  is  to  be  trained 

(a)  The  two  most  important  members  of 
the  turret  crew  -  the  tank  commander 
and  the  gunner. 

(b)  All  the  "pairs"  (gunner  and 
commander)  from  the  tanks  in  a 
platoon  under  the  command  of  a 
platoon  commander. 

Justification  :  It  is  generally  true  that 
platoon  commanders  are  either  excellent 
platoon  commanders,  in  which  case  they  tend  to 
lose  touch  with  their  own  tank  ;  or  they  are 
excellent  tank  commanders  who  tend  to  lose 
touch  with  the  platoon. 

Platoon  commanders  must  therefore  be  specially 
trained  in  company  with  the  tank  crew  teams 
they  are  commanding.  Only  a  high  performance 
training  tool  incorporating  effective 
monitoring  devices  and  operated  by  one  or  more 
Instructors  Is  capable  of  solving  this 
training  problem. 


2.  Simulator  destination.  Two  simulators 
have  been  ordered  : 

No.  1  Pi  -range  training  with  platoon 
gunnery  at  CPCIT,  CANJUERS. 
No.  2  Ecole  d1 Appl ication  de  l'Arme 
Blindee  et  de  la  Cavalerie  at 
SAUMUR  (school  roughly  equivalent 
to  Fort  Knox). 

3.  Staff  Headquarters  recoirmendations 
and  requirements. 

(a)  Visual  system  of  high  quality.  The 
landscape  must  have  excellent  definition, 
enabling  targets  such  as  tanks,  helicopters 
and  all-terrain  vehicles  to  be  detected  in  a 
real  vegetation  at  ranges  up  to  3500  meters  in 
dayl ight. 

(b)  The  device  must  be  fully  utilized. 

To  achieve  this,  the  device  must  have  the 
following  qualities  : 

-  simplicity  of  use, 

-  realism  of  scenarios,  turret  space,  aiming 
and  firing  sequences  and  effects  of  fire, 

-  reliability. 

(c)  The  device  must  have  reasonable 
acquisition  and  maintenance  costs,  and 
provide  : 

-  reduction  of  instruction  and  training  time, 
accompanied  by  an  improvement  in  quality  of 
gunnery, 

-  savings  in  resources  such  as  carriers,  fuel, 
ammunition,  ranges. 

(d)  The  device  must  be  set  up  as  quickly 
as  possible,  ideally  in  the  same  time  as  the 
operational  equipment. 

(e)  The  device  must  be  capable  of  being 
easily  modified  to  keep  pace  with  changes  to 
the  operational  equipment  and  its  uses. 


194 


4.  Organization  of  the  analysis,  design 
and  manufacture 

The  French  Army  Staff  Headquarters  gave  the 
OTAT  responsibility  for  developing  the 
program.  This  responsibility  was  delegated  to 
the  electronic  center,  the  SEFT.  THOMSON-CSF 
Division  Simulateurs  was  chosen  to  design  and 
manufacture  the  simulators  and  provide 
logistic  support.  Previously,  at  SEFT's 
request,  THOMSON-CSF  participated  in 
discussions  with  various  Staff  Headquarters 
subordinate  organizations  to  delineate  the 
capabilities  of  currently  available 
techniques.  The  outcome  of  this  analysis  phase 
was  a  good  definition  of  the  two  identical 
simulators  in  the  form  of  a  precise,  detailed 
and  complete  design  specification. 
Subsequently,  THOMSON-CSF  was  awarded  the 
contract,  but  the  discussions  continue  in  the 
form  of  four  permanent  working  groups 
(Man/machine  interfaces.  Scenarios/exercises, 
Facilities,  Role  of  the  instructor  and 
definition  of  the  instructor's  station). 

5.  Schedule 

Preliminary  statement  of  requirement  :  1 1 1/79 
Analysis  .  111/79  to  111/80 


Final  statement  of  requirement .  :  1 1 1/80 

Design  specification  .  :  1/81 

Contract  award  .  :  111/81 

Acceptance  of  1st  PGS .  :  11/84 

Delivery  of  1st  PGS  .  :  1 1 1/84 

Acceptance  of  2nd  PGS  .  :  1/85 

Delivery  of  2nd  PGS  .  :  11/85 


PGS  TECHNICAL  DESCRIPTION 

PGS  is,  at  the  present  time,  the  only 
genuine  platoon  gunnery  simulator  in 
existence.  Its  innovative  aspects  lie  both  in 
general  performance  and  in  the  technical 
designs  of  visual  and  recoil  generation 
systems.  We  shall  give  subsequently  : 


from  distances  between  each  of  the  three 
turrets  on  the  field.  Main  features  of  PGS  are 
given  in  tables  below.  They  confer  to  the  PGS 
the  following  characteristics  : 

-  high  training  realism, 

-  multipurpose  simulation, 

-  variety  of  operational  conditions, 

-  powerful  and  easy-to-use  instructor's 
facilities, 

-  maintainability, 

-  flexibility  for  future  evolution. 

(a)  High  training  realism.  A  highly 
realistic  environment  was  one  of  the  major 
basic  requirements.  This  realism  is  necessary 
when  simulating  the  mechanical,  visual  and 
aural  environments. 

-  Mechanical  environment.  Simulator  turrets 
faithfully  reproduce  the  internal  arrangement 
of  real  turrets.  This  is  achieved  by  means  of 
well  known  techniques  using  both  real  and 
simulated  equipment.  An  important  initial 
requirement  was  to  provide  the  simulator  with 
a  good  recoil  simulation.  It  is  very  important 
to  train  pupils  not  to  be  taken  by  surprise 
when  they  fire,  remaining  ready  to  observe 
their  own  results.  It  is  therefore  a  must  to 
have  a  good  mechanical  reproduction  of  the 
recoil  effects  when  rounds  are  fired.  For  this 
purpose,  the  PGS  includes  a  very  realistic 
recoil  system  acting  not  only  on  the  sights 
but  on  the  whole  turret.  The  design  of  this 
system  is  described  in  detail  belows. 

-  Visual  environment.  The  quality  of  a  gunnery 
simulator  is  closely  linked  to  the  quality  of 
its  visual  system.  Training  in  tactical 
operations  such  as  observation  and  detection 
of  targets  in  the  landscape  requires  a 
particularly  high  degree  of  realism  in  visual 
simulation.  Basic  requirements  of  this  visual 
system  are  given  in  the  tables  above.  System 
design  is  described  in  detail  below. 


1.  the  PGS  general  description 

2.  description  of  the  visual  and  recoil 
generation  systems. 

PGS  GENERAL  DESCRIPTION 

The  PGS  achieves  simultaneous  basic  and 
tactical  training  of  crews  of  3  turrets  either 
in  individual  or  in  platoon  mode. 

Personnel  to  be  trained  are  : 

-  1st  turret  :  1  platoon  commander  and 
1  gunner 

-  2  nd  turret  :  1  tank  commander  and 
1  gunner 

-  3  rd  turret  :  1  tank  commander  and 
1  gunner 

The  platoon  has  to  react  to  tactical 
situations  occuring  in  a  90°  forward  angle. 
Hull -up  and  hull -down  movements  are  simulated 
and  so  are  relative  occultations  resulting 


-  Aural  environment.  PGS  reproduces  main  sound 
effects  such  as  -  report  when  shot  is  fired  - 
idling  noise  of  the  main  engine  -  turret  drive 
system. 

(b)  Multipurpose  simulation, 
versatility,  flexibility.  PGS  is  designed  to 
meet  all  tne  training  needs  of  the  training 
centers. 

-  Functioning  according  to  different  modes  : 
Platoon  or  separate  crew  mode.  The  instructor 
has  the  capability  of  programming  simultaneous 
training  of  the  three  turrets  facing  a  common 
tactical  situation  (platoon  mode).  In  this 
case,  each  turret  can  observe  the  firing 
effects  of  the  other  turrets  in  the  platoon. 
Platoon  training  can  be  conducted  by  a  single 
instructor.  Separate  training  can  also  be 
achieved  (separate  crew  mode).  In  this  case 
training  of  each  turret  is  quite  independent. 
Separate  mode  requires  3  instructors. 


PGS  MAIN  FEATURES 


CREWS  TRAINED  SIMULTANEOUSLY  =  3  TURRET  CREW- 


TANK 

PLATOON 

TANK 

COMMANDER 

COMMANDER 

COMMANDER 

GUNNER 

GUNNER 

GUNNER 

TRAINING  AIMS 


TURRETS 

TRAINING 

.  INITIAL  TEST  OF  TURRET  (FIRE  CONTROL,  RADIO,  SIGHTS  ...) 

.  DETECTION,  RECOGNITION,  IDENTIFICATION  OF  TARGETS 
.  AIMING 

.  USE  OF  FIRING  SYSTEM  (QUICKLY  AND  ACCURATELY) 

.  FIRE  OBSERVATION  AND  ADJUSTMENT 
.  MALFUNCTIONS 

PLATOON  TRAINING 

.  COMMUNICATION  BETWEEN  TURRETS,  AND  WITH  THE  INSTRUCTOR! S ) 

.  ALLOCATION  OF  TARGETS  BY  PLATOON  LEADER 
.  FIGHTING  AGAINST  8  TARGETS  IN  THE  COMMON  LANDSCAPE 
.  PLATOON  FIRE  OBSERVATION  AND  ADJUSTMENT 

SIMULATION  FIRING  EVALUATION  CAPABILITIES  : 

-  PLATOON  TRAINING  =  FIRE  COORDINATION  BETWEEN  TURRETS 

-  PLATOON  AND  TURRET  TRAINING  =  FIRE  QUALITY  : 

.  SUCCESSION  OF  BASIC  PHASES  OF  FIRING  SEQUENCE 
.  ACQUISITION  OF  FIRING  PARAMETERS  (WIND  ...) 

.  AIMING,  RANGEFINOING  (DOUBLE-ECHO),  TACHIMETRY  ... 
.  FIRING 

.  ADJUSTMENT  OF  FIRE  FOR  NEXT  ROUND 


STATIONARY  POSITION  .  HULL-UP,  HULL-DOWN  MOVEMENTS 
TURRET  TYPES  : 

3  x  AMX  10  RC 
or  3  x  AMX  30  B2 
or  3  x  AMX  30  B 


TRAINING  MODES 

-  PLATOON  MODE  (PLATOON  +  TURRET  TRAINING) 

-  SEPARATE  CREW  MODE  (TURRET  TRAINING) 


SIMULATION  OF  ALL  PLATOON  VIEWING  DEVICES  WITH  PROPER  MAGNIFICATION 

-  GUNNER  SIGHTS 

-  TANK  COMMANDER  SIGHTS 

-  PERISCOPE 


SIMULATION  OF  RECOIL  EFFECT  ON  THE  WHOLE  TURRET 


RELATIVE  OCCULTATIONS  RESULTING  FROM  DISTANCE  BETWEEN  TURRETS 


N.B.C.  TRAINING 


PGS  VISUAL  MAIN  FEATURES 


LANDSCAPE 

REALISTIC  :  COLOR 

NATURAL  TERRAIN  FEATURES 
HIGH  RESOLUTION 

CHOSEN  BY  USER 

FIELD  OF  VISION  (F.O.V.)  =  90° 

EASY  TO  PROVIDE  ADDITIONAL  LANDSCAPES 

EASY  TO  CHANGE 

VARIOUS  LIGHTING  CONDITIONS 


TARGETS 

-  REALISTIC 

-  STATIONARY  -  MOVING 

-  MANY  SIMULTANEOUSLY  (UP  TO  8) 

-  DIFFERENT  TYPES  :  MAIN  BATTLE  TANK 

LIGHT  ARMORED  VEHICLES 
HELICOPTERS 

-  REALISTIC  ATTITUDES  ACCORDING  TO  THE 
TERRAIN.  INTELLIGENT  BEHAVIOR. 

-  MASKING  EFFECTS  :  TARGETS  -  TARGETS 

TARGETS  -  TERRAIN 

-  HIGH  DETECTION/RECOGNITION  RANGES 


FIRING  EFFECTS 

-  GUN  FLASH  AND  SMOKE 

-  IMAGE  MOVEMENT  IN  SIGHTS  WHEN  SHOT  IS  FIRED 

-  TRACER  WITH  PROPER  BALLISTICS  (AMMUNITION  TYPE,  WIND...) 

-  IMPACT  ACCORDING  TO  :  AMMUNITION  TYPE 

GROUND 

WIND 


-  MASKING  EFFECTS  :  IMPACT  -  TARGETS 
IMPACT  -  TERRAIN 


-  Training  on  any  type  of  tanks.  French  PGS 
allows  training  on  three  different  types  of 
tanks  :  AMX10RC,  AMX308,  AMX30B2 .  The  PGS 
includes  : 

-  3  AMX10RC  simulated  turrets 

-  3  AMX30  (B,B2)  simulated  turrets. 

Switching  between  AMX10RC  and  AMX30  (B,B2) 
training  is  achieved  by  : 

-  changing  of  simulated  turrets  (crews 
move  from  one  turret  type  to  the 
other) . 

-  selection  of  appropriate  software 
program  by  the  instructor. 

Switching  between  AMX30B  and  AMX30B2  training 
is  achieved  by  : 

-  subsitution  of  specific  equipment  in 
the  simulated  turrets. 

-  selection  of  appropriate  software 
program  by  the  instructor. 

These  operations  require  only  a  few  minutes. 

(c)  Variety  of  operational  conditions. 

One  of  the  major  requirements  was  to  provide  a 
large  number  of  exercices.  The  reasons  were  : 

-  To  have  a  set  of  progressively 
difficult  lessons. 

-  To  achieve  effective  training  by 
preventing  the  trainees  from 
becoming  accustomed  to  repetitive 
tactical  situations. 

The  PGS  gives  the  following  capabilities  : 

-  Several  landscapes  :  Initially,  units 
are  delivered  with  2  different 
landscapes.  Simulator  design  makes  it 
possible  to  change  the  landscape  on 
the  simulator  and  to  create  new 
landscapes  very  easily. 

-  Large  number  of  pre-progran*ned 
exercices  (200). 

-  Possibility  of  modifying  a  set  of 
parameters  such  as  target  speed  - 
wind  -  temperature  -  optional  recoil 
effects  -  at  any  time. 

-  Several  kinds  of  targets  -  main 
battle  tank  -  light  armored  vehicle  - 
helicopters. 

-  Insertion  of  malfunctions  of  firing 
system. 

(d)  Powerful  and  easy  to  use 
instructor's  facilities.  An  ergonomic  study  by 
the  users  and  manufacturer  established  two 
requirements  : 


Versatile  instructor  stations  capable  of  : 

-  programming  of  various  exercices, 

-  modification  of  main  exercice 
paramaters , 

-  supervision  of  trainees  actions  - 
display  of  firing  results  -  use  of 
training  aids  such  as  play-back, 
freeze,  trainees  evaluation  ...  etc. 

Easy-to-use  equipment  :  all  these  functions 
are  achievable  by  means  of  very  simple 
operations. 

(e)  Maintainabi 1 ity.  Maintainability 
factors  were  taken  into  account  at  the  very 
beginning  of  the  design  of  the  PGS.  Proven 
technologies  and  a  modular  design  have  been 
used  whenever  possible.  A  full  set  of  built-in 
tests  are  provided  to  achieve  : 

-  Quick  tests  to  check  the  overall 
correct  operation  of  the  simulator. 

-  Diagnostic  tests  for  the  visual 
system  isolating  the  faulty  board 
(and  often  the  faulty  components  on 
the  board). 

-  Adjustment  tests  and  associated  tools 
for  easy  bore-sighting  of  the  system. 

(f)  Flexibility  for  future 
modifications.  It  was  of  great  importance  to 
provide  the  PGS  with  the  capability  of  being 
modified  as  a  result  of  changes  in 
operational  or  technical  requirements.  Here  we 
can  give  some  examples  of  the  possibilities  of 
evolution  which  have  been  taken  into  account 
in  the  initial  design  : 

-  Addition  of  a  4th  turret  in  the 
platoon. 

-  Additional  landscapes. 

-  Additional  types  of  targets. 

-  Night  firing. 

-  Head  up  and  binocular  vision. 

-  Programming  of  exercices  by  the 
instructors. 

-  Additional  simulated  sound  effects 
(closing  of  breech,  cartridge 
ejection). 

-  Adaptation  to  any  king  of  firing 
system. 

VISUAL  SIMULATION 
General  organization 

The  visual  simulation  system  is  designed  to 
provide  independent  images  for  the  various 
viewing  devices  of  the  turrets.  These  viewing 
devices  are  the  following  : 
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-  Sights  :  PGS  provides  each  sight  with 
images  at  the  correct  magnification. 

Each  sight  allows  independent 
observation  anywhere  in  the  landscape. 
The  sights  simulated  are  the  gunner 
and  tank  commander  primary  and 
auxiliary  sights.  Identical 
performance  is  simulated  for  primary 
and  auxiliary  sights  of  the  same 
trainee.  This  allows  the  use  of  only 
one  generation  system  for  both  sights. 
Therefore,  the  total  image  generation 
system  consists  of  6  independent 
sights  simulations  (3  gunners  and  3 
tank  commanders). 

-  Periscopes  :  the  three  frontal 
periscopes  of  each  turret  are 
simulated.  Together  they  cover  the 
field  of  view  of  90°  (3  x  30°),  equal 
to  the  total  field  of  view  (FOV)  of 
the  simulation. 

3  main  sources  are  used  to  build  the  images  : 

-  landscape  generator, 

-  targets  generator, 

-  firing  effects  generator. 

Landscape  generator. 

This  source  generates  the  images  of  a 
realistic  color  landscape  over  a  90°  FOV  for 
each  viewing  device,  with  appropriate 
magnification. 

(a)  Limitations  of  available 
techniques.  A  first  step  in  our  study  was  to 
investigate  the  use  of  available  techniques. 
Unfortunately,  all  of  them  revealed  some 
important  limitations  with  regard  to  the 
requirements. 

CGI  systems  have  been  developed  and  used  in 
many  aircraft  applications.  In  the  case  of 
gunnery  simulation,  they  have  proven  suitable 
when  their  application  is  limited  to  aiming 
and  firing  operations.  But  we  have  to  rule 
them  out  as  soon  as  tactical  training  is 
considered.  This  is  currently  due  to  their 
lack  of  realism  for  a  reasonable  price.  If  and 
when  future  improvements  in  this  technique 
make  them  suitable  for  these  applications,  PGS 
configurations  may  then  be  able  to  utilize 
them. 

Model  board  techniques  give  a  relatively  high 
degree  of  realism.  This  advantage,  together 
with  a  reasonable  cost  makes  them  particularly 
suitable  for  some  applications  such  as  Tank 
Driving  Simulators.  Unfortunately,  model  board 
techniques  have  a  serious  limitation  in  that 
it  is  pratically  impossible  to  insert  a 
large  number  of  moving  objects  (targets, 
firing  effects)  while  ensuring  a  high 
flexibility  in  their  trajectories  and 
atti tudes. 


Another  solution  is  to  store  a  digitalized 
photograph  of  the  landscape  and  to  observe  at 
any  moment  the  relevant  part  of  it  tor  each 
viewing  device.  Such  a  solution  requires  high 
capacity  memories  when  color  and  many  viewing 
devices  are  requested.  It  also  requires  high 
data  exchange  speed  between  mass  memory  and 
working  memories. 

(b)  PGS  solution  :  flying  spot 
scanners.  The  chosen  solution  consists  of  a 
color  slide  and  a  flying  spot  scanner  for  each 
viewing  device.  The  color  slide  represents  the 
whole  landscape  at  magnification  dependent  on 
the  field  of  view  of  the  simulated  sight. 

The  flying  spot  scans  the  portion  of  the 
landscape  to  which  is  directed  the  object  lens 
of  the  simulated  sight.  It  delivers  a  high 
resolution  color  TV  signal  (875  lines).  Aiming 
of  the  gun  in  azimuth  and  elevation  is 
simulated  by  moving  the  landscape  slide.  Slide 
movements  are  produced  by  a  carriage  system 
servo  controled  by  the  general  purpose 
computer  in  accordance  with  operation  of  the 
aiming  controls. 

The  flying  spot  scanner  system  has  the 
following  advantages  over  a  TV  camera  : 

875  lines  standard  resolution,  no  registration 
problem,  easy  to  adjust,  better  signal  to 
noise  ratio. 

The  advantages  of  this  solution  are  the 
following  : 

-  high  realism,  due  to  the  color 
slides, 

-  high  resolution  due  to  875  lines  TV 
standard, 

-  ease  of  adding  new  landscapes, 

-  ease  of  changing  landscapes, 

-  possibility  of  inlaying  moving 
objects  (targets,  firing  effects)  by 
the  use  of  TV  techniques. 

Target  generator 

The  target  generation  system  inlays  up 
to  eight  targets  in  every  viewing  device  of 
the  PGS.  Attitudes  of  targets  are  very 
faithfully  reproduced  according  to  the 
terrain. 

We  have  chosen  a  specific  technique  which 
constist  of  : 

-  storing  every  possible  target 
attitude  in  a  digital  library, 

-  inlaying  the  correct  attitude  in  the 
terrain  image  after  processing  (size 
adjustement,  masking  effects, 

etc. . . ). 

The  following  paragraphs  give  a  brief 
explanation  of  the  target  processing  which  is 
achieved  by  mean  of  a  fast  computer  CRP  24 
especially  developped  by  TH0MS0N-CSF  for 
visual  applications. 


(a)  Target  storage.  Every  possible 
attitude  of  the  target  in  rotation,  roll  and 
pitch  is  stored  on  a  disk. 

The  number  of  different  attitudes  is  2500.  The 
angular  increment  varies  from  1°  to  3° 
according  to  the  position  of  the  target  (front 
of  lateral  position).  These  increment  values 
give  excellent  continuity  in  target  movement. 
Size  of  the  stored  targets  correspond  to  the 
largest  apparent  target  size  according  to 
target  type,  target  range  and  sight 
magnification. 
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Each  attitude  is  stored  in  a  matrix  of  64  x  32 
points.  PGS  is  provided  with  files 
corresponding  to  three  target  types  : 

-  main  battle  tank, 

-  light  armored  vehicle, 

-  helicopter. 


(e)  Target  inlaying  in  the  landscape. 
Each  target  is  inlayed  in  the  lanscape  image 
of  each  viewing  device  by  means  of  video 
techniques. 

Anti-aliasing  is  used  to  provide  very 
continuous  target  motion  in  the  image 
(increment  of  1024  pixels  on  a  TV  line). 

(f)  Target  Trajectories.  Target 
trajectories  are  defined  in  a  very  simple  way 
in  a  specific  file  containing  segment 
descriptions.  Insertion  of  targets 
trajectories  in  the  landscape  is  then  achieved 
automatically  by  means  of  the  processing 
described  above. 

Creation  of  new  trajectories  can  be  easily 
accomplished  by  the  user.  This  operation 
requires  no  equipment  other  than  the  existing 
equipment  of  the  simulator. 


(b)  Choice  of  correct  attitude.  The 
general  purpose  computer  also  includes  a  file 
describing  the  relief  of  the  landscape.  This 
file  is  organized  as  a  grid  of  altitudes. 
Minimum  distance  between  2  altitudes  is 
30  meters.  This  is  sufficient  to  faithfully 
describe  the  relief. 

At  any  time  the  computer  can  choose  the 
correct  attitude  by  comparing  the  position  of 
the  target  with  the  relief  file. 

Use  of  a  high  resolution  TV  standard  gives 
long  detection  or  recognition  range.  The  table 
below  gives  the  resolution  in  TV  lines  of  a 
target  2.5  m  high,  seen  through  a  simulated 
optical  system  of  107  milliradians  (sight)  and 
533  milliradians  (periscope). 


Target  range 

Resolution 

FOV  107  mrd  FOV  533  mrd 

800  m 

24  lines 

5  lines 

2000  m 

10  lines 

2  lines 

3500  m 

6  lines 

2  lines 

(c)  Masking  generation.  The  general 
purpose  computer  possesses  a  masking  file 
describing  the  outlines  and  ranges  of 
landscape  elements. 

Descriptions  of  masks  around  targets  are  input 
to  the  fast  comput  CRP  24  which  processes  the 
masking  priority  between  target,  firing 
effects  and  landscape. 

We  must  stress  how  easily  the  relief  and 
masking  files  are  created.  They  can  be 
generated  by  semi-automatic  procedures  using 
PGS  equipment. 

(d)  Scale  processing.  The  fast 
specialized  CRP  24  computer  performs  real  time 
scale  processing  on  tagets  according  to  : 

-  their  range, 

-  sight  magnification. 


Targets  can  be  assigned  an  intelligent 
behavior.  A  program  sends  them  realistically 
to  the  nearest  cover  when  they  come  under  fire 
from  the  platoon. 

Firing  Effects  Generator 

Simulation  of  the  visual  effects 
related  to  firing  consists  of  reproducing  : 

-  the  effects  when  the  shot  is  fired  - 
burst  of  flame,  then  smoke 
interfering  with  observation, 

-  the  tracer  of  each  shell, 

-  the  effects  of  impact  -  explosion, 
smoke,  target  hit. 

(a)  Firing  of  the  Shot.  The  simulator 
reproduces  the  difficulties  of  observation 
when  the  shot  is  fired,  created  by  the  burst 
of  flame  from  the  gun  muzzle  and  the  smoke. 

These  effects  are  simulated  as  follows  : 

-  burst  of  flame  :  yellow  coloring  of 
the  images  observed  through  the 
simulated  sights, 

-  smoke  :  transition  from  yellow  to 
white  of  the  images  observed  through 
the  simulated  sights.  The  smoke  then 
gradually  dissipates. 

(b)  Tracer 

-  The  tracers  of  all  the  shells  fired  are 
simulated. 

-  The  shell's  trajectory  faithfully  simulates 
the  real  trajectory.  It  takes  into  account  the 
ballistics  specific  to  each  type  of  ammunition 
and  the  influence  of  cross-wind,  air 
temperature  and  altitude. 

-  Dipersion  of  the  weapon/ammunition  pair  is 
simulated  by  random  functions,  highly 
representative  of  real  dispersion. 
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-  The  tracer  is  masked  when  the  shell 
penetrates  a  "soft"  mask  (bushes,  leaves)  and 
when  it  passes  behind  a  "hard"  mask  (building, 
tree  trunk  or  the  target  itself)  but  does  not 
hit  it. 

(c)  impact.  The  flash  and  smoke  of 
impact  are  displayed  in  the  periscopes  and 
the  sights.  In  platoon  mode,  the  same  impact 
can  be  observed  by  all  the  turrets  of  the 
platoon. 

in  individual  mode,  the  crews  see  only  the 
impact  of  their  own  shells. 

-  Target  hit  :  this  hit  is  viewed  as  an 
explosion  with  release  of  yellow  light.  The 
target  which  has  been  hit  continues  to  move  a 
few  meters  under  its  own  impetus  then  stops 
after  turning  blackish. 

-  Target  miss  :  in  the  event  of  a  target  miss, 
impact  of  the  shell  on  the  ground  is  viewed  as 
a  release  of  smoke,  the  amount  of  which  varies 
according  to  the  type  of  ammunition  and  the 
shape  of  which  depends  on  the  cross  wind.  The 
smoke  may  be  fully  or  partially  masked  when 
impact  with  the  ground  occurs  behind  the 
target,  a  building,  a  clump  of  trees  or  in  a 
fold  of  the  terrain.  It  may  also  mask  a  target 
or  a  terrain  feature  when  it  takes  place  in 
front  of  the  target  or  terrain  feature.  All 
these  effects  are  generated  by  video  methods. 


RECOIL  SIMULATION 

Purpose 

A  very  realistic  simulation  of  recoil 
was  a  key  initial  requirement.  In  this 
simulation,  we  have  developed  a  recoil  system 
moving  the  whole  simulated  turret. 

Description 

Turrets  are  mounted  on  guide  rails. The 
recoil  simulation  system  moves  the  cabin 
horizontally  in  the  axis  of  the  gun  when  shots 
are  fired.  The  amplitude  and  variations  of  the 
movement  as  function  of  time  are  such  that  the 
crew  perceives  it  as  the  recoil  due  to  real 
fighting.  The  recoil  simulation  system 
includes  : 

-  a  fixed  structure  with  anchor  points 
for  the  guide  system, 

-  a  moving  structure  to  which  the  cabin 
is  attached, 

-  a  pneumatically  controlled  motion 
system  recreating  :  -  a  violent 
reaction  at  gun  recoil  and 
longitudinal  oscillations  -  the 
damped  return  of  the  turret  to  its 
initial  position. 


Simultaneously,  the  images  through  the  sights 
move  vertically,  giving  the  trainees 
complementary  cues  of  turret  motion  due  to  the 
firing  effect. 

TRAINING  PGS  POTENTIAL 


Preliminary  tests  conducted  in  19/9  on 
a  research  prototype  gave  the  conclusions  of 
the  next  table. 


TRAINING  PGS  POTENTIAL  (Example) 

(8  hours/day  -  21  days/month) 

CREW  TRAINING 

PLATOON  TRAINING 

DAILY 

96  exercices  15’each  16 

exercices  30'each 

1400  shells 

1000  shells 

MONTHLY 

2000  exercices 

330  exercices 

30000  shells 

20000  shells 

The  equipment  is  capable  of  being  used  if 
necessary,  16  hours  a  day,  7  days  a  week. 


CONCLUSION 

PGS  appears  to  be  an  efficient  tool  to 
achieve  basic  and  tactical  training  of  platoon 
c  rews . 

Operational  advantages  of  PGS  are  twoflod  : 

(a)  Training  is  more  realistic  than  on 
an  exercice  terrain  because  the  simulation 
gives  a  better  approach  to  combat  situations. 
This  has  been  proven  by  the  research 
prototype.  Reasons  are  the  following  : 

-  the  battlefields  are  absolutely 
natural  and  more  realistic  than  the 
bare,  shell  raked  firing  ranges  on 
which  the  location  and  displacement 
of  the  targets  is  overly  familiar  to 
the  crews. 

-  the  battlefields  are  interchangeable, 
which  is  not  the  case  with  firing 
ranges  of  which  only  a  limited  number 
exist. 

-  the  targets  are  identifiable  and 
viewed  at  all  attitudes. 

-  as  in  combat,  the  targets  bound, 
zigzag  in  open  country,  remain 
exposed  for  a  minimum  time  and  are 
difficult  to  detect  and  hit. 

-  as  in  combat,  the  large  number  of 
enemy  attack  scenarios  make  it 
impossible  to  remember  previous 
target  trajectories. 

-  as  in  combat,  when  a  target  receives 
a  direct  hit,  it  blackens  and  stops 
moving. 

-  as  in  combat,  a  target  under  attack 
heads  for  the  nearest  cover. 


The  recoil  system  includes  protective  systems 
designed  to  ensure  personnel  safety. 
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-  finally,  and  this  is  an  essential 
point,  simulation  of  the  shot  leaving 
the  muzzle,  its  trajectory  and  its 
impact  on  the  ground  or  the  target, 
reproduces  all  the  difficulties  of 
tank  gunnery  and  observation  of  the 
shots,  and  obliges  the  tank 
conroanders  to  adjust  the  fire  of  the 
other  vehicles  in  the  platoon. 

The  multiple  features  of  the  PGS  provide 
progressive  training  ranging  from  the 
initiation  to  gunnery  procedures,  to  the 
tactical  conduct  of  fire  of  a  full  platoon. 

(b)  Training  is  more  effective  and 
more  rapid  than  with  conventional  means 
because  : 

-  all  the  actions  of  a  member  of  the 
platoon  or  a  tank  crew  are 
immediately  detected  and  any  error 
can  be  corrected  using  the  playback. 

-  continuous  and  detailed  recording  of 
firing  results  provides  an  objective 
evaluation  of  each  crew  member's 
performance,  making  a  considerable 

contribution  to  crew  motivation. 

Innovative  technical  designs  in  the  visual  and 
recoil  simulation  bring  a  useful  contribution 
to  the  family  of  existing  systems.  These 
solutions  are  ideal  for  many  training 
applications  (tanks,  missiles,  etc...).  It  is 
also  interesting  to  note  that  the  same 
techniques  can  be  used  to  build  turret 
simulators  (gunner  and  tank  commander)  capable 
of  being  fitted  in  a  tractor  towed  trailer, 
making  it  independent  of  all  local 
infrastructures  and  readily  available  for  use 
at  different  sites. 
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SYNTHETIC  APERTURE  RADAR  SIMULATION 
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ABSTRACT 

During  the  1980's,  a  new  generation  of  airborne  radar  systems  will  become  operational. 
These  radars  will  have  a  number  of  new  capabilities,  but  their  synthetic  apertures  will  have 
the  greatest  impact  on  simulation  of  the  system  since  they  provide  a  tenfold  increase  in 
resolution.  Increased  radar  landmass  simulator  resolution  is  not  the  only  problem  implied 
by  this  increase.  In  particular,  the  sparsity  of  the  DMA  data  bases  presents  a  challenge  in 
the  generation  of  realistic  images.  Other  new  requirements  include  the  simulation  of  anoma¬ 
lies  caused  by  Doppler  mapping.  For  the  last  two  years.  Link  has  conducted  an  R4D  program 
to  explore  the  requirements  of  these  new  generation  radars.  This  paper  reports  on  the 
results. 


INTRODUCTION 

Over  the  next  decade,  a  number  of  new  air¬ 
borne  radar  systems  will  be  introduced  for  such 
aircraft  as  the  F-16,  the  F-15,  the  B-l ,  the 
F-5,  and  the  F-18.  These  new  multimode  radars 
have  significantly  greater  capabilities  than 
present  real -beam  systems. 

The  new  radars  will  enable  users  to  perform 
a  large  number  of  new  tasks  and  perform  them 
much  better  than  before.  These  radars  have  the 
following  modes  or  capabilities:  Real -Beam 
Ground  Mapping,  Synthetic  Aperture/Doppler  Beam 
Sharpening  Ground  Mapping,  Ground  Tracking, 
Terrain  Avoidance,  Terrain  Following,  Air-to- 
Air,  Weather,  Moving  Target  Indication,  and 
Electronic  Agility. 

This  multitude  of  capabilities  allows  the 
crew  to  perform  missions  not  previously  possi¬ 
ble,  but  at  the  same  time  requires  that  the  crew 
be  given  additional  training.  The  present  gen¬ 
eration  DRLMS  systems  are  not  adequate  for  this 
purpose.  Doppler  Beam  Sharpening  and  Synthetic 
Aperture,  two  virtually  indistinguishable  modes, 
require  the  greatest  changes  in  simulation 
technology. 


TYPES  OF  MISSIONS 

For  strategic  aircraft,  the  addition  of 
synthetic  aperture  capability  will  primarily 
affect  three  tasks:  navigation,  weapon 
delivery,  and  damage  assessment.  In  all  three 
of  these  tasks  the  crew  will  be  able  to  sig¬ 
nificantly  Improve  its  performance  because, 
instead  of  the  100-foot  resolution  of  real-beam 
radars,  the  new  systems  will  have  resolutions  of 
10  feet  or  less.  Not  only  will  it  be  possible 
to  Increase  the  accuracy  of  navigational  up¬ 
dates,  but  also  smaller  landmarks  not  previously 
discernible,  can  be  used  as  checkpoints. 

For  tactical  aircraft  the  increased  resolu¬ 
tion  means  that  the  pilot  will  be  able  to  use 
the  radar  to  detect  and  identify  targets,  such 
as  individual  tanks,  and  to  use  the  radar  in 
weapon  delivery  on  these  targets.  (See  Figure 


For  both  strategic  and  tactical  aircraft, 
the  crew  must  be  trained  to  use  the  much  higher- 
resolution  image  and  to  cope  with  some  of  the 
anomalies  of  synthetic  aperture  radars.  The 
crew  must  also  be  trained  to  correlate  radar  and 
other  sensor  (IR  and  LLTV)  images. 

These  goals  can  be  reached  only  if  the 
simulator  can  produce  realistic  images  with 
resolutions  typical  of  SAR  and  if  the  system  can 
simulate  the  anomalies  of  SAR/DBS.  Moreover, 
for  effective  training,  the  simulator  should  be 
able  to  reproduce  the  failure  modes  encoun¬ 
tered  in  synthetic  aperture  systems. 

In  the  following  sections  the  limitations 
of  the  present  hardware  and  data  base  for  SAR 
simulation  will  be  discussed,  together  with  a 
proposed  approach  for  a  SAR  DRLMS. 


DMA  DATA  BASE 

The  DMA  data  base  has  four  levels  of  detail. 
For  any  level,  the  data  are  organized  into  two 
files:  terrain  elevation  file  and  planimetry 
file.  The  first  of  these  contains  only  eleva¬ 
tion  data  at  grid  points.  All  other  information 
resides  in  the  planimetry  file,  which  consists 
of  "features.”  A  feature  may  be  a  lake,  an 
urban  development,  a  single  house,  or  even  a 
power  pole.  Each  feature  is  described  by  a  type 
code  and  a  surface  material  designation.  The 
geometry  of  each  feature  is  defined  by  a  series 
of  vectors  circumscribing  the  ground  projection 
of  the  feature,  together  with  its  height. 


The  end  points  of  the  vectors  are  defined 
in  terms  of  geodetic  coordinates  for  all  levels 
at  a  precision  of  +/-  0.1  arc  second.  This  cor¬ 
responds  to  about  10  feet  at  the  equator,  and 
less  elsewhere.  Consequently,  the  precision  of 
the  data  is  adequate  for  generating  simulated 
SAR  images.  The  deficiency  of  the  DMA  data  base 
for  very-high-resolution  radar  is  in  the  amount 
of  data  Included.  Even  the  highest  level  of 
detail,  Level  X,  by  no  means  contain  all  objects 
10  feet  in  size  or  larger;  only  features  of 
tactical  significance  are  encoded. 


Figure  1  DEMONSTRATION  OF  THE  8.5  FT  RESOLUTION  CAPABILITY  OF  THE  HUGHES  APG-63  RADAR. 
ARRAY  CONSISTS  OF  84  TANKS,  11  FT  BY  20  FT  IN  SIZE,  56  FT  APART. 


Most  of  the  areas  are  covered  only  by  the 
lowest  level  of  detail.  Level  I.  At  this  level 
a  residential  area  may  be  described  only  as  a 
single  feature  of  several  square  miles,  with  a 
designated  percentage  of  roof  and  tree  cover. 
Individual  houses  or  streets  are  not  defined. 

Even  highways  are  not  Included  in  most  cases, 
although  Edition  2  of  Level  I  (to  be  issued 
shortly)  will  contain  lines  of  connunication. 

Apart  from  lacking  much  detail,  the  DMA 
data  base  also  omits  some  features  required  for 
realistic  SAR  simulation,  such  as  airplanes, 
tanks,  trucks,  and  ships.  Clearly  such  data 
cannot  be  present  in  the  data  base,  but  are  of 
great  importance  in  training. 

Finally,  the  coverage  is  still  Incomplete. 
Eurasia,  the  only  area  targeted  for  complete 
coverage,  will  not  be  available  In  Its  entirety 
prior  to  1992  even  at  the  lowest  level  of  detail. 
There  are  no  plans  at  present  to  provide  overall 
coverage  at  any  higher  level  of  detail. 

IMPACT  OF  HIGHER  RESOLUTION 

Since  the  emergence  of  SAR  a  number  of 
Ideas  about  SAR  simulation  have  been  advanced. 

One  has  been  that  the  simulation  of  these  radars 
will  require  a  great  deal  more  hardware  because 
a  tenfold  Increase  of  linear  resolution  Implies 
that,  over  a  two-dimensional  Image,  a  100-fold 
Increase  of  processing  will  be  required.  This 
view  ignores  the  fact  that  a  typical  radar, 
which  uses  a  raster  type  of  display,  has  about 
360,000  picture  elements,  and  the  number  of  pic¬ 
ture  elements  Is  the  same  regardless  of  the 
resolution  of  the  radar.  The  computational  load 
Is  primarily  a  function  of  the  number  of  picture 
elements  and  the  number  of  features  In  the  Image 
area.  Absolute  accuracy  Is  not  the  determining 
factor,  only  relative  accuracy  Is.  The  relative 
accuracy  for  a  high-resolution  Image  Is  the  same 


as  for  low-resolution,  long-range  radar.  From 
the  computational  point  of  view,  the  greatest 
loads  occur  at  low  resolution  and  long  ranges 
where  the  number  of  features  is  the  greatest 
within  the  radar  scan.  Thus  earlier  systems 
which  had  adequate  processing  capacity  are  suit¬ 
able  for  the  SAR  requirements,  when  the  addi¬ 
tional  capabilities  discussed  below  are  incor¬ 
porated. 

It  could  be  said  that  the  problem  is  not 
that  SAR  requires  too  much  computation,  but  the 
opposite:  the  data  base  is  too  sparse  and, 
without  enhancement,  will  not  yield  a  realistic 
image. 

This  observation  has  given  rise  to  the 
second  fallacy:  since  present  data  bases  do  not 
have  detail  comparable  to  that  seen  on  SAR 
images,  there  is  little  point  in  developing  a 
new  SAR  simulator.  That  is,  present  real -beam 
radar  DRLMS  systems  are  adequate,  since  the 
limitation  lies  in  the  data  base,  not  the 
simulator. 

This  thinking  would  lead  to  simulators  that 
can  produce  only  the  imagery  typical  of  low- 
resolution,  real -beam  radars.  But  this  approach 
would,  in  effect,  ignore  the  stringent  training 
requirements  of  the  SAR  systems. 

The  solution  to  the  problem  is  to  supple¬ 
ment  the  DMA  data  base.  Although  augmenting  the 
data  base  to  include  every  object  discernible  on 
SAR  would  clearly  be  prohibitive,  it  is  cer¬ 
tainly  feasible  to  manually  insert  the  required 
data  in  small  restricted  areas,  such  as  around 
navigational  checkpoints.  The  necessary  source 
material  for  this  enhancement  is  obtainable  from 
aerial  photographs,  maps,  or  actual  SAR  imagery. 
For  strategic  missions,  this  is  clearly  satis¬ 
factory,  since  SAR  is  to  be  used  only  at  a  few 
checkpoints  and  target  areas. 
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In  tactical  training,  the  area  to  be 
covered  is  much  larger  because  the  mission  may 
include  the  detection  of  targets  in  a  large  com¬ 
bat  zone.  While  this  requirement  places  a 
greater  burden  on  the  data  base,  the  fidelity  of 
the  image  to  the  real  world  need  not  be  as  great 
as  for  strategic  missions.  Certainly  in  a  resi¬ 
dential  area  the  location  of  every  house  is  not 
required  for  training.  What  is  important  is  the 
ability  to  generate  the  signature  of,  for  exam¬ 
ple,  typical  residential  neighborhoods  and  the 
capability  to  insert  targets,  such  as  tanks, 
into  such  an  area.  Such  data  bases  can  train 
the  pilot  to  detect  the  target  in  the  presence 
of  extraneous  objects  and  to  use  the  radar  in 
weapon  del i very . 

Consequently,  the  real  requirement  is  to 
produce  data  bases  that  faithfully  represent  the 
general  character  of  the  actual  area,  but  pro¬ 
vide  accurate  detail  only  in  small  areas  of 
specific  interest.  This  result  can  be  achieved 
at  a  moderate  cost. 

A  potential  side  effect  of  realistic  SAR 
simulation  will  be  loss  of  correlation,  in  some 
instances,  between  the  SAR  images  and  visual/IR/ 
Low  Light  Level  Images.  This  problem  is  attrib¬ 
utable  to  the  fact  that  present  visual  systems 
which  utilize  Computer  Image  Generation  (CIG) 
techniques  do  not  provide  the  amount  of  detail 
that  SAR  simulators  can  deliver.  New  techniques 
in  the  visual  area  have  the  promise  of  eliminat¬ 
ing  these  potential  disparities. 

ENHANCEMENT  OF  THE  DATA  BASE 

There  are  two  distinct  requirements  in  the 
enhancement  approach:  how  to  insert  features  of 
tactical  significance  into  the  data  base  and  how 
to  produce  generic  detail.  The  methods  are 
distinct  and  will  be  discussed  separately. 

The  insertion  of  specific  detail  of  tact¬ 
ical  significance  Is  not  new  to  radar  simula¬ 
tion.  Many  present  systems  have  this  capability 
in  the  form  of  an  Interactive  graphics  program 
that  allows  the  modification  of  the  real-time 
data  base.  This  program,  called  the  Small  Area 
Update  Routine,  is  capable  of  adding,  modifying, 
or  deleting  a  feature.  The  basic  technique  will 
not  be  affected  by  a  tenfold  Increase  In  resolu¬ 
tion. 

However,  because  of  the  higher  volume  of 
enhancement  activity,  it  will  be  desirable  to 
achieve  a  higher  level  of  automation  and  of 
computer-aided  support.  One  approach  to  this 
requirement  Is  to  utilize  the  same  type  of 
Interactive  data  base  graphics  methods  employed 
for  the  CIG  system.  Commonality  of  graphics 
hardware  and  software  will  streamline  the  data 
base  generation  process  and  at  the  same  time 
make  the  correlation  of  visual  and  radar  data 
bases  easier. 

The  second  data  base  enhancement  task  is  to 
produce  realistic  generic  radar  signatures.  As 
an  example,  one  may  want  to  produce  radar  re¬ 
turns  from  a  residential  area  described  in  the 
data  base  as  30$  roof  cover  and  40$  foliage. 

There  are  two  basic  approaches  that  one  may 
use  to  achieve  this.  This  first  is  a  fairly 


obvious  one:  replace  the  single  feature  of  a 
residential  area  by  a  multitude  of  individual 
buildings,  trees,  etc.,  arranged  in  a  typical 
way.  This  approach,  while  straightforward,  has 
two  significant  disadvantages:  the  data  base 
used  by  the  simulator  would  increase  signifi¬ 
cantly  in  size,  and  the  computational  load  on 
the  hardware  would  also  increase. 

The  other  approach  is  very  much  akin  to  the 
inclusion  of  “texture"  in  visual  systems. 

Rather  than  augmenting  the  data  base  with  syn¬ 
thetic  material  and  processing  this  extra  data 
in  the  hardware,  it  is  possible  to  incorporate 
into  the  hardware  a  "synthetic  signature  genera¬ 
tor."  This  generator  uses  table  look-up  methods 
to  provide  the  necessary  detail  to  generate  the 
signature  of  typical  areas.  As  an  example,  a 
collection  of  buildings,  streets  and  vegetation 
would  be  generated  in  response  to  a  code  speci¬ 
fying  a  suburban  single  family  residential 
area.  Because  this  code  is  converted  to  "build¬ 
ings,  etc."  relatively  late  in  the  computation 
process,  the  hardware  loading  from  this  approach 
is  considerably  less  than  synthetically  generat¬ 
ing  a  data  base  with  comparable  detail  off-line 
and  processing  this  data  base  in  the  hardware. 

A  typical  radar  image  generated  by  the  Synthetic 
Signature  Generator  is  shown  in  Figure  2. 


Figure  2  OUTPUT  OF  THE  SYNTHETIC  SIGNATURE 
GENERATOR  FOR  AN  URBAN  AREA.  IMAGE  MADE  BY  THE 
LINK  EMULATION  LABORATORY. 


SAR  ANOMALIES 

Apart  from  the  problem  of  producing  higher- 
resolution  Images,  SAR  differs  from  real-beam 
radar  in  the  way  the  azimuth  angle  is  varied  in 
the  scanning  process.  In  real -beam  radars,  the 
azimuth  angle  is  incremented  either  by  physi¬ 
cally  rotating  the  dish  or  by  antenna  phasing. 

In  either  case,  the  azimuth  resolution  is  lim¬ 
ited  by  the  dish  size:  the  larger  the  antenna, 
the  higher  the  resolution.  Physical  limitations 
In  the  aircraft,  therefore,  determine  the  reso¬ 
lution  of  the  radar.  A  discussion  of  theoret¬ 
ical  aspects  of  these  anomalies  can  be  found  in 
Reference  1 . 


For  SAR,  the  site  of  the  dish  is  not  the 
determining  factor  in  resolution  because  azimuth 
discrimination  is  achieved  by  calculating  the 
doppler  shift  in  the  radar  return  caused  by  the 
motion  of  the  aircraft  with  respect  to  the 
ground.  Objects  along  the  velocity  vector  of 
the  aircraft  will  have  frequency  shifts  of 
2fv/c,  where  f  is  the  frequency  of  the  radar  and 
v  and  c  are  the  velocities  of  the  aircraft  and 
of  light,  respectively,  while  returns  from 
objects  perpendicular  to  the  velocity  vector  of 
the  aircraft  undergo  no  frequency  shift.  The 
azimuth  angle  of  any  return  may  then  be  calcu¬ 
lated  from  its  doppler  shift. 

The  actual  radar  image  generated  in  an  SAR 
mode  is  a  mapping  of  range  versus  doppler  shift 
rather  than  of  range  versus  azimuth  angle  as  in 
real -beam  radar.  This  can  cause  anomalies. 

First  of  all,  there  is  an  ambiguity:  more  than 
one  point  on  the  ground  may  have  the  same  dop¬ 
pler  shift  and  range  if  the  terrain  is  not 
flat.  In  general,  there  is  a  mapping  distortion 
of  any  object  not  in  the  ground  plane.  In  most 
cases,  this  distortion  is  not  objectionable 
because  a  small  displacement  of  a  feature  will 
not  seriously  affect  the  mission.  Furthermore, 
if  the  elevation  of  the  object  is  known,  as  in 
the  case  of  a  navigational  checkpoint,  it  Is 
possible  to  adjust  for  the  error.  More  serious 
is  the  case  where  the  distortion  affects  the 
interpretation.  This  may  occur,  for  example, 
when  a  tall  building  is  located  adjacent  to  a 
river.  The  height  of  the  building  will  cause  a 
mapping  error  that  can  locate  the  radar  return 
In  the  middle  of  the  river!  The  operator  may 
conclude  that  this  Is  a  ship,  not  a  building. 
This  mapping  distortion,  also  called  layover,  is 
a  function  of  the  squint  angle  and  under  some 
circumstances  will  result  only  in  an  insigni¬ 
ficant  amount  of  di splacement.  The  operator 
clearly  must  be  trained  to  recognize  when  there 
is  mapping  distortion.  (See  Figure  3.) 


Other  unusual  effects  may  occur  whenever 
the  return  comes  from  a  moving  surface.  For 
example,  waves  on  the  shore  may  produce  a  dif¬ 
ferent  frequency  shift  than  might  be  expected 
from  the  shore's  physical  location.  On  a  radar 
map  this  would  manifest  itself  as  a  displacement 
from  the  shore's  actual  location.  As  a  result 
the  return  may  be  superimposed  on  the  adjacent 
terrain. 

Moving  vehicles  cause  similar  problems.  A 
train  is  displaced  so  that  its  return  is  mapped 
a  significant  distance  from  the  track.  Although 
the  train  itself  is  displaced,  its  shadow  is 
not.  (See  Figure  4.)  Unless  they  are  properly 
trained  in  the  anomalies  of  SAR,  operators  are 
likely  to  misinterpret  the  image. 

Finally,  the  azimuth  resolution  of  SAR 
decreases  as  the  squint  angle  approaches  the 
velocity  vector.  Operators  should  be  trained  so 
that  targets  do  not  go  undetected  as  a  result  of 
this  limitation  of  SAR  systems. 

HARDWARE  MODIFICATIONS  REQUIRED  BY  SAR 

The  mapping  distortion  due  to  elevation 
differences  requires  some  additions  to  the  basic 
hardware  of  the  DRLMS.  This  subsystem  is  simi¬ 
lar  to  the  hardware  needed  to  implement  beam 
spread  (horizontal  antenna  lobe)  effect.  Both 
effects  constitute  a  distortion  of  the  image  in 
the  azimuth  direction.  This  distortion  is  a 
function  of  the  squint  angle  and  is  most  pro¬ 
nounced  for  small  angles. 

The  decrease  of  resolution  as  a  function  of 
squint  angle  is  easily  simulated,  but  its 
mechanization  can  cause  problems  because  the 
various  radars  tend  to  treat  this  problem  dif¬ 
ferently.  In  some  cases,  the  radar  will  allow 
the  resolution  to  decrease  naturally  up  to  a 
certain  point  when  the  system  automatically 
switches  to  real-beam  mode.  In  other  instances, 
the  synthetic  aperture  computation  time  is 
extended  to  preserve  the  resolution.  Yet 
another  approach  is  to  prohibit  synthetic 
aperture  mode  for  small  squint  angles.  Any  of 
these  mechanizations  can  be  simulated  at  the 
cost  of  additional  hardware. 

Over  the  past  two  years  Link  has  completed 
the  system  design  of  a  SAR  DRLMS  system  capable 
of  simulating  these  effects.  The  least  signifi¬ 
cant  bit  in  the  computation  of  the  vertices  cor¬ 
responds  to  .05  arc  seconds,  or  about  5  feet  at 
the  equator,  less  elsewhere.  This  insures  that 
the  full  precision  of  the  DMA  data  base  is  pre¬ 
served.  Care  was  also  taken  to  ensure  that  none 
of  the  accuracy  in  the  DMA  data  base  will  be 
degraded  in  other  ways.  The  new  real  time  data 
base  uses  the  geodetic  coordinate  system,  the 
same  one  used  by  DMA.  This  will  eliminate  the 
loss  of  accuracy  caused  by  the  transformation  to 
the  real  time  data  base  and  greatly  simplify  and 
reduce  the  cost  of  real  time  data  base  genera¬ 
tion.  Moreover,  world-wide  flight  and  modifica¬ 
tion  of  the  data  base  become  much  simpler. 


Figure  3  LAYOYER  OF  TALL  BUILDING  AT  SMALL 
SQUINT  ANGLE.  SIMULATED  IMAGE  MADE  FROM  DMA 
DATA  BASE  BY  THE  LINK  EMULATION  LABORATORY. 


The  system  is  capable  of  handling  five  mil¬ 
lion  feature  vertices  per  second.  In  addition, 
a  great  deal  of  detail  can  be  added  by  using  the 


Figure  4a  RADAR  IMAGE  OF  MOVING  TRAIN.  FOR  INTERPRETATION,  REFER  TO  FIGURE  4b. 
PHOTOGRAPH  MADE  BY  APG-63  RADAR  ON  F-15  AIRCRAFT. 

(COURTESY  OF  HUGHES  AIRCRAFT  COMPANY. ) 


I 


Figure  4b  ILLUSTRATION  OF  DISTORTION  CAUSED  BY 
MOVING  TRAIN 


Synthetic  Signature  Generator.  Vertices  pro¬ 
duced  by  this  generator  are  not  counted  In  the 
five  million  vertices  per  second  capacity  of  the 
system.  By  using  the  Synthetic  Signature  Gener¬ 
ator  It  Is  possible  to  produce  Images  with 
several  thousand  objects  per  square  mile. 

One  would  expect  that  the  higher  resolution 
of  SAR  would  Increase  the  required  size  of  the 
on-line  data  base.  In  fact,  the  size  of  the  data 
base  Is  smaller  for  the  SAR  DRLMS  than  for  the 
previous  generation  DRLMS.  This  Improvement  Is 
attributable  to  a  more  efficient  method  of  stor¬ 
ing  the  data  and  also  to  an  algorithm  that  com¬ 
presses  the  elevation  data. 


Although  the  Link  SAR  DRLMS  will  have  sig¬ 
nificantly  greater  capabilities  than  the  present 
one,  the  amount  of  hardware  and  the  cost  will  be 
comparable  to  present  systems.  This  advance  was 
achieved  by  Introducing  various  innovations  and 
simplifications  in  the  basic  algorithms  through 
a  thorough  study  of  the  computational  require¬ 
ments.  These  led  to  architectural  changes 
resulting  In  more  efficient  hardware  utiliza¬ 
tion.  Finally,  a  great  deal  of  the  credit  for 
Improved  cost  performance  should  be  given  to  the 
use  of  VLSI  and  VHLSI  advances  In  semiconductor 
technology. 

To  ensure  that  all  these  goals  are  reached. 
Link  made  extensive  use  of  computer  emulation  of 
the  system.  The  Images  generated  by  emulating 
the  hardware  were  then  compared  to  actual  SAR 
photographs. 

SIMULATION  OF  MALFUNCTIONS 

SAR  systems  have  all  the  failure  modes 
encountered  In  real -beam  radars.  In  addition, 
one  may  also  encounter  problems  caused  by  equip¬ 
ment  extraneous  to  the  radar.  For  example,  a 
problem  In  the  Inertial  navigation  system  of  the 
aircraft  may  produce  a  mapping  distortion.  This 
can  occur  when  a  velocity  error  exists  in  the 
navigation  system.  An  offset  In  the  aircraft's 
velocity  will  produce  an  azimuth  distortion  of 
the  Image.  (An  object  located  at  one  o'clock 
relative  to  the  aircraft  may  appear  at  two 
o'clock.)  The  pilot  can  recalibrate  and 
correct  this  error,  but  only  If  he  Is  able  to 
recognize  the  problem.  Therefore,  training  Is 
essential . 
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CONCLUSION 


ABOUT  THE  AUTHOR 


Present  DRLMS  systems  cannot  satisfy  the 
training  requirements  of  SAR.  Changes  must  be 
made  to  both  the  data  base  and  the  hardware,  but 
these  changes  are  feasible;  the  overall  cost  of 
these  requirements  should  not  increase  the  cost 
of  the  simulators,  because  advances  in  semicon¬ 
ductor  technology  and  system  architecture  more 
than  compensate  for  the  new  requirements. 
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TN  ELECTRONIC  WARFARE  TRAINERS 
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The  design  of  an  FW  trainer  involves  a  derision  to  simulate  EW  functions  via  computer 
software  or  to  incorporate  actual  EW  hardware  within  the  trainer  and  stimulate  it  with 
required  signals.  This  paper  compares  the  requirements  and  relative  advantages  of  software 
simulation  vs.  hardware  stimulation  in  EW  trainers.  Aspects  discussed  include  cost  of  hard¬ 
ware  and  software,  computer  load,  trainer  fidelity  to  real-world  conditions,  documentation 
and  data  requirements,  interaction  among  EW  units,  testing  requirements,  and  trainer  modifi¬ 
cation.  Both  approaches  have  particular  advantages  and  problems  in  each  of  these  areas.  In 
conclusion,  the  choice  of  simulation  or  stimulation,  or  mixture  of  both,  in  a  given  trainer 
should  be  based  on  careful  studv  of  particular  c i reumst ances  and  requirements. 


INTRODUCTION 

Electronic  warfare  trainers  are  designed  to 
provide  a  student  with  training  on  electronic 
warfare  equipment  acting  in  an  EW  environment. 
In  a  typical  trainer  the  environment  consists  of 
a  number  of  radar  emitters  scattered  throughout  a 
war  gaming  area,  emitting  signals  that  are 
received  by  tie  student's  ownship.  The  EW  equip¬ 
ment  in  the  trainer  nay  include  radar  receivers 
and  analyzers,  chaff  and  flare  dispensers,  jam¬ 
mers,  and  so  forth. 

Many  trainers  involve  training  on  specific  F.W 
equipment,  such  as  a  particular  model  of  radar 
warning  receiver  or  jammer.  When  such  specific 
equipment  is  included  in  a  trainer  the  design 
question  arises:  should  the  trainer  simulate  the 
equipment  via  computer  software  or  should  the 
trainer  include  actual  equipment  that  is  stimu¬ 
lated  to  produce  the  desired  effects? 

This  paper  examines  the  question  of  simula¬ 
tion  vs  stimulation,  par t leui ar ly  with  regard  to 
radar-based  trainers,  and  draws  on  experience 
with  EW  trainers  developed  bv  AAT  Corporation  for 
A-10  and  F-lb  aircraft  flight  simulators.  Both 
trainers  include  the  AN/ALR-69  Radar  Warning 
Receiver  and  other  EW  equipment.  The  A-10  F.W 
trainer  includes  an  actual  AI,R-b9  unit  stimulated 
with  video  pulse  trains,  while  in  the  F- 1 6 
trainer  the  ALR-b9  is  simulated  entirely  bv 
computer  software. 


TRATNER  CONFIGURATIONS 

A  modem  training  simulator  for  electronic 
warfare  consists  of  several  major  functional 
components,  as  illustrated  in  Figure  J.  A  threat 
environment  Is  generated  and  continuously  updated 
by  several  related  functions.  A  mission  genera¬ 
tion  module  defines  the  environment  and  places 
the  trainer’s  ownship  within  the  environment.  A 
threat  tactics  module  defines  the  signal  genera¬ 
tion  modes  of  the  threats,  thus  defining  the 
types  of  signals  to  be  generated.  Further 
processing  defines  exact  charar ter i st 1 cs  of  the 
threat  signals.  Ownship  countermeasures  such  as 
lamming,  chaff,  flares  and  maneuvering  nav  he 


made  to  affect  the  threats'  signal  generation 
modes . 


Figure  1.  EW  Trainer  Conf igurat f on 


The  signal  processing  functions  are  then 
performed.  Threat  signals  are  analyzed  according 
to  the  algorithms  employed  by  the  equipment 
Associated  with  the  trainer.  Processing  may  be 
performed  by  actual  EW  equipment  or  may  be  simu¬ 
lated  by  computer  software.  This  signal 
processing  may  be  simple  or  elaborate  according 
to  equipment  characteristics  and  trainer  require¬ 
ments.  Outputs  from  the  signal  analysis  are  used 
to  drive  display  hardware  consisting  of  display 
screens,  indicator  lights,  and  speakers. 


Figures  2  and  1  compare  implementat ions  of 
the  basic  functional  design  in  Figure  1.  The 
definition  of  the  threat  environment,  and  all  of 
its  associated  activities,  must  almost  neces¬ 
sarily  be  implemented  in  computer  software.  Even 
if  some  Functions  may  be  performed  bv  digital 
hardware  circuits,  this  hardware  i^  merely  per¬ 
forming  logical  functions  that  assist  in  the 
threat  simulation.  The  real  choice  comes  in  the 
area  of  signal  processing  equipment.  Tf  it  is  to 
be  simulated  as  in  Figure  2,  computer  software 
defines  the  signal  characterist ics,  simulates  the 
signal  processing  functions  and  triggers  hardware 
to  drive  the  displays.  Tf  a  stimulation  is  used 
as  in  Figure  1,  the  threat  environment  definition 
software  directs  pulse  generators  to  generate 
pulse  trains  which  are  sent  to  the  signal 
processing  hardware.  This  hardware  then  performs 
whatever  signal  processing  is  appropriate  and 
generates  output  to  drive  the  display  hardware. 


Figure  2.  Software  Simulation 

Tn  reality,  nearly  every  trainer  includes 
both  simulation  and  stimulation  techniques  to 
some  degree.  A  s t imula t ion-oriented  trainer  will 
include  a  simulation  of  the  threat  environment 
and  computer-controlled  generation  of  threat 
signals.  Furthermore,  a  simulation  trainer  must 
include  some  signal  generation  if  only  to  drive 
display  hardware  or  produce  audio  tones.  The 
real  question  centers  around  the  number  and  type 
of  functions  to  be  implemented  by  simulation  or 
stfnulat ion . 

A  discussion  of  the  relative  merits  of 
simulation  versus  stimulation  involves  a  number 
of  considerations  such  as  the  cost  of  hardware 
and  software,  trainer  fidelity  to  real  world 


conditions,  donimont at  ion  and  data  requirements, 
testing  requ i remon t s  and  trainer  modifications. 


Figure  3.  Hardware  Stimulation 


COST 

Tf  a  hardware  stimulation  is  being  con¬ 
sidered,  the  cost  and  availability  of  the  EW 
hardware  must  be  taken  into  account.  Advanced  EW 
equipment  may  be  very  expensive  and  its  inclusion 
into  the  trainer  may  increase  its  cost  signifi¬ 
cantly.  Even  if  the  EW  hardware  is  provided  as 
Government  Furnished  Equipment  the  overall  cost 
to  the  customer  must  include  the  cost  of  the 
equipment.  The  availability  of  the  equipment 
must  he  considered  as  well.  Tf  few  of  the  units 
are  manufactured,  if  all  of  the  units  are  com¬ 
mitted  to  other  purposes,  or  if  the  units  are  out 
of  production,  it  may  be  difficult  to  obtain 
units  for  Inclusion  in  the  trainers.  The  cost  of 
maintenance  and  updating  facilities  for  the  EW 
equipment  must  also  he  taken  into  account. 

The  cost  of  support  hardware  and  software  in 
the  trainer  can  he  considerable  as  well.  A 
complex  EW  environment  requires  a  bank  of  signal 
generators  for  stimulating  the  EW  equipment. 
Special  effects  such  as  scan  patterns  and  range 
attenuation  are  produced  by  further  hardware. 
All  of  these  signals  must  be  coordinated  and 
interfaced  with  the  EW  equipment.  The  design, 
testing  and  manufacture  of  this  hardware  can  run 
to  sizeable  expense,  especially  if  thr*  hardware 
configuration  is  large  and  elaborate. 

A  hardware  stimulation  also  requires  special 
software  to  control  the  signal  generation  hard¬ 
ware.  When  a  threat  enters  the  environment,  a 
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signal  generator  must  he  selected,  loaded  with 
pulse  generation  data  if  necessarv  and  turned  off 
when  the  threat  leaves  the  environment.  Special 
hardware  effects  are  also  controlled  hv  software. 
The  cost  of  design,  development  and  testing  of 
this  software  must  be  included  into  the  special 
costs  of  a  hardware  stimulation. 

The  cost  of  a  software  simulation  must  be 
weighed  against  the  cost  of  a  hardware 
stimulation.  As  described  earlier,  a  modern 
training  simulator  relies  heavily  on  a  computer 
to  perform  a  number  of  supervisory  and  simulation 
functions.  The  computer  generates  and  controls 
the  threat  environment  and  mav  interact  with 
ownship  and  visual  systems.  The  addition  of  a 
software  simulation  of  F.W  equipment  may  not 
involve  an  extremely  large  further  effort. 
However,  as  will  he  discussed  later,  development 
and  testing  of  simulation  software  can  pose  maior 
difficulties.  And  if  specific  EW  equipment  is 
being  simulated,  it  is  likelv  that  the  actual 
equipment  will  undergo  revisions.  The  cost  of 
changing  the  software  to  simulate  these  revisions 
can  be  quite  large. 

Software  simulations  hold  a  definite  produc¬ 
tion  cost  advantage  in  trainers  where  many  units 
are  to  be  produced.  Once  the  original  simulation 
has  been  developed,  additional  units  are  produced 
merely  by  copying  the  software  onto  the  mass 
storage  devices  of  the  new  units.  This  is  a 
trivial  part  of  copying  general  simulation  soft¬ 
ware  to  the  new  system. 

Producing  new  hardware  stimulation  units 
requires  more  effort  and  expense.  Not  only  must 
the  EW  equipment  he  procured  and  installed,  but 
the  signal  generation  hardware  for  each  new  unit 
must  be  manufactured  and  tested.  Each  new  unit 
thus  incurs  significant  new  production  costs. 

Simulation  and  stimulation  therefore  both 
involve  their  own  special  costs.  The  relative 
costs  of  each  vary  from  trainer  to  trainer, 
depending  on  the  equipment  configurations  and 
numbers  of  units  involved. 


DOCUMENTATION  AND  DATA  REQUIREMENTS 

Software  simulation  and  hardware  stimulation 
both  have  their  special  data  requirements.  A 
software  simulation  requires  extensive  docu¬ 
mentation  on  the  EW  equipment  being  simulated.  A 
realistic  trainer  must  be  based  on  detailed 
specifications  of  all  displays  produced  by  the 
equipment,  including  threat  indications  on 
display  screens,  patterns  of  flashing  lamps, 
audio  tones,  and  so  forth.  Processing  of  various 
emitters  must  be  described  in  sufficient  detail 
to  imitate  the  sane  results  as  produced  by  the 
actual  EW  equipment.  In  the  case  of  a  signal 
processor  analyzing  a  dense  threat  environment, 
the  designers  of  a  simulation  will  require  a 
large  amount  of  threat  data  and  sufficient 
functional  documen t a t f on  to  develop  software 
processes  that  handle  the  threats  in  the  same 
manner  as  does  the  EW  hardware. 

A  realistic  software  simulation  should  not 
only  generate  the  maior  functions  of  the  EW 


equipment,  but  should  also  reproduce  subtle  ,»ud 
anomalous  effects  found  in  the  actual  EW  units. 
Complex  EW  hardware  nav  produce  unexpected 
effects  in  extreme  or  unusual  combinations  of 
circumstances.  In  normal  operation  the  equipment 
nav  exhibit  unwanted  side  effects  on  its 
displays,  and  hidden  hugs  in  the  EW  equipment 
software  mav  alter  the  basic  standard 
specifications.  An  ideal  simulation  would 
reproduce  all  of  these  effects.  However,  some  of 
these  effects  mav  have  little  or  no  training 
value  and  thus  mav  not  be  required  in  specifi¬ 
cations  for  the  trainer.  For  other  effects,  no 
definite  information  mav  be  available,  rendering 
these  effects  impossible  to  simulate  with  anv 
rea 1  ism. 

Considering  the  extent  of  the  data  that  could 
be  required  for  a  realistic  software  simulation, 
it  is  essential  chat  the  spec  i  f  i  cat  ions  for  the 
simulation  describe  the  behavior  to  be  simulated 
and  the  data  available  on  this  behavior.  Tn  the 
absence  of  adequate  data,  the  software  designers 
must  either  ignore  the  behavior  or  make  their  own 
guesses  about  spec  i  f  icat  iorts . 

Hardware  stimulation  mav  likewise  require  a 
large  amount  of  data  and  functional  description. 
On  the  hardware  level,  timing  diagrams,  pulse 
widths,  bus  protocols,  etc.,  must  be  specified 
exactly  since  input  signals  are  fed  into  EW 
equipment  itself.  These  speci f icat ions  may  seem 
straightforward,  but  problems  may  develop  in 
actual  interfacing  with  the  EW  hardware.  The  EW 
hardware  may  not  perform  exactly  as  described  in 
the  specifications,  or  it  might  have  requirements 
not  clearly  stated  in  the  interfacing  protocols. 
Solving  these  kinds  of  problems  will  require 
further  research  to  discover  modified  or  hidden 
requirements. 

The  functional  requirements  of  the  inputs 
must  likewise  be  specified  carefully.  EW  equip¬ 
ment  that  performs  elaborate  and  discriminating 
signal  analysis  will  probably  require  highly 
realistic  inputs.  The  designers  of  the 
stimulation  equipment  will  thus  require  complete 
data  on  all  of  the  signals  to  be  input  into  the 
EW  equipment.  In  the  absence  of  explicit  input 
parameter  data  for  particular  rases,  it  may  be 
necessary  to  "reverse-engineer”  the  input  data 
from  the  signal  analysis  processes  used  by  the  EW 
equipment.  This  may  require  detailed  and  precise 
information  on  the  exact  algorithms  used  within 
the  EW  equipment.  At  times  this  data  requirement 
may  be  more  exacting  than  for  a  software 
simulation  design. 

However,  given  the  correct  Inputs,  a  hardware 
stimulation  should  bv  its  nature  produce  all  of 
the  Intended  and  anomalous  effects  generated 
internally  or  by  the  inputs.  Not  onlv  will  the 
major  and  minor  display  effects  appear  realisti¬ 
cally,  but  special  peculiarities  and  overload 
behavior  will  perform  the  same  as  in  field 
units.  Fidelity  to  real  world  phenomena  is  thus 
more  attainable,  as  the  EW  equipment  is 
presenting  realistic  displays  to  the  trainee. 
Once  again  though,  the  realism  of  the  output 
depends  on  the  realism  of  the  stimulating  inputs. 
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INTERACTIVE  EFFECTS 

An  F.W  trainer  becomes  particularly  complex 
when  it  contains  several  pieces  of  EW  equipment 
interacting  with  each  other  under  power  manage¬ 
ment  or  some  other  configuration.  The 
interactions  between  the  units  can  be  particu¬ 
larly  difficult  to  simulate,  especially  in  the 
areas  of  subtle  and  anomalous  effects  which  may 
be  poorly  understood.  When  the  actual  EW  units 
are  installed  in  the  trainer  and  connected 
together,  they  automat ical ly  produce  all  of  the 
subtle  interactive  effects  that  may  be  extemely 
difficult  to  reproduce  in  a  software  simulation. 

On  the  other  hand,  if  the  additional  F.W  units 
are  quite  simple  or  require  extensive  additional 
signal  inputs,  a  software  simulation  nay  be 
simpler  and  more  cost-effective.  However,  a 
software  simulation  interacting  with  hardware  is 
subject  to  difficulties  both  in  software  develop¬ 
ment  and  in  hardware  interfacing. 


TESTING 

Simulation  and  stimulation  trainers  each  have 
particular  testing  requirements.  Testing  of  a 
hardware  stimulation  is  presumably  more  straight¬ 
forward,  as  the  EW  equipment  is  expected  to 
produce  a  set  of  well-known  results.  As  was 
noted  earlier,  the  major  and  minor  displays, 
anomalies  and  pecularities  should  be  documented 
beforehand  and  observable  during  testing. 
However,  if  unpredicted  results  appear  during 
testing,  the  origin  of  the  problem  may  be 
difficult  to  pinpoint.  The  chain  from  input  data 
specification  through  signal  generation  to  signal 
analysis  and  display  contains  a  number  of 
separate  links,  each  quite  distinct  from  the 
others.  The  nature  of  the  problem  may  make  it 
difficult  to  determine  whether  the  Inputs  have 
been  generated  incorrectly  or  whether  the  EW 
equipment  Is  exhibiting  a  heretofore  unknown 
anomaly.  If  the  output  results  are  not  according 
to  specif ication,  it  may  be  that  the  inputs  are 
not  sufficiently  realistic  for  processing  by  the 
EW  equipment.  More  elaborately  realistic  inputs 
may  be  required  to  produce  the  correct  results. 
On  the  other  hand,  an  unexpected  output  from  the 
EW  equipment  may  be  a  correct  result  that  has  not 
previously  been  documented.  Unusual  signals  or 
combinations  of  signals  may  produce  results  that 
have  not  been  observed  prior  to  the  testing  of 
the  trainer.  In  this  case,  the  testing  personnel 
will  have  to  re-evaluate  the  test  criteria  and 
revise  them  accordingly. 

A  software  simulation  can  be  more  difficult 
to  debug  and  test.  All  of  the  output  effects 
originally  specified  for  the  trainer  must  be 
tested  and  evaluated.  Since  the  effects  are 
being  artificially  generated,  they  do  not 
automatically  display  the  realism  associated  with 
a  stimulation.  Thus  disagreements  may  arise 
during  testing  as  to  whether  the  simulated  effect 
is  acceptably  realistic.  Furthermore,  the  full 
range  of  secondary  and  subtle  effects  of  the 
actual  EW  equipment  are  rarely,  if  ever,  pro¬ 
grammed  Into  the  simulation.  Unless  the  list  of 
required  effects  has  been  carefully  specified 
beforehand,  testing  the  simulation  may  give  rise 
to  disagreements  over  whether  particular  effects 


that  have  boon  omitted  are  actual  lv  n.-c*-ss  i 
Unfortunate  1 y ,  manv  such  effects  arc  not  rcudilv 
specified  beforehand  and  can  he  defined  and 
judged  onlv  upon  inspection  of  the  simul  i!  ion 
itself.  Unforeseen  anomalies  mav  arise  during 
testing  of  a  software  simulation  as  well.  In  a 
well-structured  software  program  the  source  of 
such  anomalies  ran  he  identified  fairlv  readilv, 
but  it  is  more  difficult  to  determine  whether 
they  properly  belong  in  the  simulation.  The 
simulation  designers  can  claim  that  the  anonalv 
is  a  necessary  co  n  s  e  q  u e  n  c e  of  a  realistic 
simulation,  while  the  testing  personnel  denv  that 
the  EW  field  units  exhibits  such  behavior.  Onlv 
an  examination  of  actual  equipment  operation  can 
determine  whether  the  behavior  reallv  occurs. 


MAINTENANCE  AND  UPDATES 

Hardware  stimulation  and  software  simulation 
both  require  continual  maintenance  and  updating 
once  the  trainer  has  been  installed.  EW 
equipment  included  in  the  trainer  will  require 
periodic  or  emergency  maintenance,  probably  bv 
trained  personnel.  Such  maintenance  must  be 
provided  for  either  at  the  trainer  site  or  at  the 
depot  level.  In  addition,  the  EW  equipment  will 
probably  undergo  revisions  in  the  field.  In  this 
case  the  equipment  in  the  trainer  must  be  modi¬ 
fied  if  it  is  to  be  kept  current  with  the  field 
units.  Such  modifications  are  typically  easy  to 
make  on  modern  military  electronics  equipment,  as 
they  usually  involve  little  more  than  the 
replacement  of  printed  circuit  boards.  This 
modification  can  be  performed  as  part  of  a 
program  of  revisions  to  field  units.  Even  if  the 
revision  of  the  EW  equipment  is  simple  to 
perform,  a  revision  to  the  EW  equipment  may  have 
consequences  for  the  rest  of  the  trainer.  Any 
significant  alteration  of  input  requirements  may 
require  changes  to  the  signal  generation 
processes  of  the  trainer.  The  EW  revisions  mav 
require  improved  or  altered  signal  modeling, 
entirely  new  inputs  or  altered  timing  of  existing 
inputs.  Changes  may  be  required  in  signal 
hardware  or  even  in  the  simulation  software  and 
involve  far  more  effort  than  the  EW  equipment 
modification  itself. 

Modi f icat ions  to  a  software  simulation  are 
typically  more  difficult  to  perform  as  the 
hardware  revisions  must  be  studied,  modeled, 
implemented  in  software  and  tested.  The  software 
changes  must  go  through  the  entire  design  and 
development  process  and  are  subjected  to  the  same 
difficulties  in  testing  as  were  discussed 
earlier.  This  is  particularly  true  if  the  EW 
equipment  revision  results  in  s i gn  i  f i c an 1 1 v 
altered  outputs  or  new  anomalous  behavior.  Data 
on  the  new  requirements  must  he  procured  and 
studied,  even  though  documentation  on  the 
revision  may  be  incomplete  or  difficult  to 
obtain.  The  effects  of  the  revision  must  be 
evaluated  and  modeled  and  included  into  the 
simulation  software.  The  original  software 
typically  does  not  provide  for  such 
modifications,  so  integrating  them  into  the 
original  software  mav  not  he  a  simple  matter. 
Finally,  testing  of  the  modification  is  subject 
to  the  difficulties  discussed  earlier,  narticu- 
larly  if  the  operational  effects  of  the  revision 
have  not  been  extensively  documented. 
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However,  ordinary  maintenance  of  a  softwr 
simulation  is  much  easier.  Once  the  trainer  i 
in  place,  the  EW  software  will  not  require  anv 
maintenance  unless  hidden  software  bugs  are 
noticed.  Anv  maintenance  on  the  computer  CPU  or 
peripherals  takes  place  as  part  of  normal 
computer  operation  and  is  not  specifically 
chargeable  to  the  EW  simulation  software, 

CONCLUSION 

Hardware  stimulation  and  software  simulation 
both  have  their  advantages  and  shortcomings  in  EW 
trainers.  A  hardware  stimulation  includes  actual 
F.W  equipment  that  already  comes  with  a  full  range 
of  realistic  output  behaviors,  both  intended  and 
anomalous,  that  can  be  used  directly  for  highly 
realistic  training  on  the  F.W  equipment  involved. 
If  it  is  part  of  a  larger  system,  the  EW  equip¬ 
ment  will  interface  with  other  components  of  the 
system  without  further  development  effort,  and 
revisions  to  the  F.W  equipment  can  be  made  rela¬ 
tively  easily  as  part  of  a  general  field  update 
program. 

Actual  F.W  hardware  may  present  some  problems, 
however.  The  F.W  equipment  itself  may  be 
extremely  costly  or  unavailable  for  a  number  of 
reasons.  The  software  and  hardware  required  in 
the  trainer  to  produce  all  of  the  required  inputs 
may  be  difficult  to  design  and  expensive  to  pro¬ 
duce,  and  modifications  to  the  EW  equipment  may 
have  ramifications  in  the  trainer  that  extend 
beyond  the  EW  hardware  itself, 

A  software  simulation  can  prove  to  be  less 
costly  to  design  and  produce  if  exact  realism  is 
not  required  or  if  many  units  are  to  be  built. 
Since  a  modern  trainer  performs  many  functions 
via  a  computer,  the  addition  of  an  EW  ecmipment 
simulation  module  may  involve  only  a  moderate 
additional  effort.  A  software  simulation  also 
bypasses  the  elaborate  signal  generation  hardware 
required  bv  EW  equipment  stimulation. 


A  so  ft  war*1  simulation  has  difficulties  of  irs 
•wn.  Trainer  realism  can  be  most  difficult  t<> 
achieve,  and  mav  he  impossible  to  define  and 
assess.  Furthermore,  mod f f i ca t i ons  to  the  simu¬ 
lation  require  a  full  design  and  development 
process . 

Neither  approach  has  an  overwhelming 
advantage  over  the  other,  and  both  have  their 
merits  when  used  in  the  appropriate  situation.  A 
generic  trainer  involving  no  specific  EW 
equipment  and  providing  only  generalized  training 
should  ohviouslv  use  a  software  simulation.  Anv 
trainer  in  which  EW  is  secondary  or  in  which 
moderate  realism  is  necessary  is  also  a  candidate 
for  the  software  approach.  On  the  other  hand,  a 
trainer  that  relies  heavily  on  detailed  training 
on  specific  EW  equipment  should  probably  use 
hardware  stimulation  to  achieve  greatest  realism. 
Furthermore,  the  greater  the  complexity  of  the  EW 
system  involved,  the  greater  the  advantage  of 
stimulation.  Even  here,  however,  recent  advances 
in  computer  hardware  and  software  techniques  have 
made  highly  realistic  software  simulations 
possible.  Thus  each  trainer  design  should  he 
considered  separately  and  the  approach  of  simu¬ 
lation  versus  stimulation  chosen  according  to  the 
particular  requirements  of  the  trainer. 
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ABSTRACT 

This  paper  describes  a  generic  model  for  use  on  a  sonar  trainer  that  simulates 
the  propulsion  systems  (including  engines,  turbines,  shafts,  and  propellers) 
for  most  vessels  in  use  today  without  predefining  the  specific  vessel  types. 
These  vessel  types  include  surface  ships,  submarines,  torpedoes,  and  decoys 
which  the  instructors  can  create  or  alter  by  modifying  a  set  of  table  driven 
model  constants  without  the  necessity  of  changing  the  basic  structure  of  the 
model.  The  model  provides  for  realistic  simulations  of  propulsion  mode 
transition  dynamics  and  allows  for  interruptions  of  transitions  already  in 
progress.  The  model  is  suitable  for  sonar  classification  training,  and 
further,  is  aaaptable  to  a  variety  of  training  systems  which  would  require  a 
high  fidelity  target  radiated  acoustic  signature  simulation. 


INTRODUCTION 

Modeling  ship  propulsion  systems  such  as 
engines,  turbines,  shafts,  and  propellers 
for  simulating  target  radiated  acoustics 
in  sonar  trainers  has  traditionally  been 
done  by  using  unique  models  for  each  type 
of  ship.  These  traditional  approaches 
result  in  significant  modifications  and 
added  cost  to  the  computer  software  when 
changes  to  the  vessel  are  required. 

A  Navy  surface  ship  sonar  trainer  ( NT EC 
device  14E27A)  currently  in  development, 
will  avoid  these  modification  problems 
with  an  approach  that  allows  the 
instructors  to  define  the  specific  vessel 
characteristics.  The  fidelity  of  the 
simulation  can  be  adjusted  by  the 
instructor  because  of  the  generic 
structure  of  the  model.  Thus,  the 
instructor  can  provide  the  proper  level  of 
realism  that  is  desired  for  each  vessel 
type.  By  involving  the  users  of  the  system 
directly  in  the  development  of  the 
trainer's  capabilities,  the  sonar  trainer 
will  be  more  responsive  to  the  system 
user's  needs. 

Typical  propulsion  systems  are  described, 
and  the  overall  model  structure  which 
simulates  these  systems  is  developed.  The 
instructor  interaction  in  controlling  the 
simulated  propulsion  systems,  as  well  as 
in  fine  tuning  for  fidelity,  is  explained. 

TYPICAL  VESSEL  PROPULSION  SYSTEMS 

A  sonar  trainer  will  usually  employ  many 
different  types  of  vessels  in  the  acoustic 
simulation  of  targets  in  the  ocean 
enviroment.  The  most  important  of  these 


vessel  types  are  surface  ships, 
submarines,  torpedoes,  and  decoys.  An 
accurate  simulation  of  the  passive 
acoustic  signature  of  each  vessel  is  an 
important  component  to  the  task  of  sonar 
classification  training.  Since  the 
propulsion  systems  are  a  prime  contributor 
to  the  acoustic  signature  of  a  vessel,  it 
is  important  to  have  a  high  fidelity 
acoustic  simulation  of  these  system 
elements . 

Vessel  propulsion  systems  include  many 
different  types  of  components  including 
the  following  (see  Figure  1.) : 

1.  Engines  (both  diesel  and  gas/steam 
turbine) 

2.  Shafts/propellers 

3.  Electric  generators 

4.  Electric  motors 

5.  Miscellaneous  equipment  such  as 
pumps,  reduction  gears,  clutches 


Figure  1.  Engine/Shaft  Drive  Train  Components 


BASIC  MODEL  STRUCTURE 


Acoustically,  the  first  four  elements  in 
the  list  above  are  usually  the  major 
contributors  to  the  acoustic  noise 
generated  by  a  vessel  when  it  is  moving. 
The  miscellaneous  equipment  is  either 
transient  in  nature  or  is  acoustically 
related  to  one  of  the  four  main 
components . 

A  vessel  will  generate  two  basic  types  of 
acoustic  energy,  tonal  and  broadband. 
Tonal  sound  is  concentrated  into  narrow 
frequency  segments  (or  harmonic  groups  of 
segments) ,  such  as  the  whine  of  a 
generator  (see  Figure  2.).  Broadband  sound 
is  basically  continuous  over  a  wide  range 
of  frequencies,  such  as  the  hiss  of  steam 
(see  Figure  3.).  For  sonar  classification 
purposes,  the  tonal  sound  is  much  more 
important  than  the  broadband.  Therefore, 
the  propulsion  simulation  concentrates  on 
the  elements  that  produce  primarily  tonal 
acoustic  energy  in  the  vessel . 
Consequently,  the  steam  generator  (if 
used)  is  not  an  important  component  in  -:he 
acoustic  model  of  the  vessel's  propulsion 
systems,  even  though  it  is  very  important 
for  actual  propulsion.  This  type  pf 
broadband  noise,  however,  is  included  irn 
general  broadband  radiated  noise  levels 
which  provide  for  training  in  sonar 
detection  of  vessels,  and  to  realistically 
obscure  the  classification  tonal 
components . 
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Figure  2.  Tonal  Sound  Spectrum 


FREQUENCY 


Figure  3.  Broadband  Sound  Spectrum 


Since  there  are  a  large  number  of  vessel 
types  that  are  of  interest  today  for  a 
sonar  trainer,  modeling  the  propulsion 
systems  for  each  one  of  them  would  be  very 
complex  and  cumbetsore.  A  better  approach, 
used  in  the  14E27A  sonar  trainer,  is  to 
develop  a  generic  propulsion  model  that 
can  be  configured  to  simulate  the 
important  features  of  any  particular 
vessel  type. 

A  vessel  will  typically  have  multiple 
engines,  shafts,  propellers,  motors,  and 
generators.  The  propulsion  model  allows 
for  up  to  four  shafts  and  propellers  which 
will  accomodate  even  the  largest 
battleships  and  carriers  in  use  today.  The 
model  makes  the  following  simplifications: 

1.  Each  propeller  for  a  multiple  shaft 

vessel  will  have  the  same 
characteristics  (turns-per-knot , 

number  of  blades,  diameter). 

2.  Each  shaft  for  a  multiple  shaft 
vessel  will  be  considered  as  an 
independent  engine/shaft  drive  train. 
No  implicit  interaction  is  allowed 
between  different  drive  trains. 

3.  Each  drive  train  will  consist  of  an 
independent  set  of  the  following 
components: 

a.  Engine 

b.  Electric  Generator 

c.  Electric  Motor 

d.  Shaft  and  Propeller 

Note  that  some  vessel  types  may  not 
use  all  of  these  components. 

4.  Each  drive  train  will  have  a  limited 
set  of  internal  interconnections, 
referred  to  as  a  configuration,  as 
follows : 

a.  Engine  is  off-line 

(disconnected) ,  shaft  is 

off-line 

b.  Engine  is  directly 

(mechanically)  driving  the  shaft 

c.  Engine  is  off-line,  an  electric 
motor  is  directly  driving  the 
shaft 

d.  Engine  is  driving  an  electric 
generator,  shaft  is  off-line 

e.  Engine  is  driving  an  electric 
generator,  an  electric  motor  is 
directly  driving  the  shaft 

Note  that  some  vessel  types  may  not 
use  all  of  these  configurations. 

5.  Only  fixed  blade  propellers  are 
modeled.  There  is  no  provision  for 
variable  pitch  props.  In  addition, 
only  forward  propeller  thrust  is 
available  since  the  model  does  not 
allow  for  the  propellers  to  be 
reversed . 
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Even  with  these  simplifications,  the  model 
provides  a  great  deal  of  fidelity  and 
flexibility  for  virtually  every  type  of 
vessel  of  interest  for  sonar 
classification  training  purposes.  A 
particular  set  of  configurations  for  each 
engine/shaft  drive  train  in  the  vessel  is 
called  a  propulsion  mode.  For  many 
vessels,  there  may  be  very  few  modes  used 
in  practice,  especially  for  merchant  type 
surface  ships.  In  contrast,  a  diesel 
submarine  will  usually  have  many 
propulsion  modes  available.  The  model  uses 
these  modes  along  with  other  data  to 
control  the  RPM  of  all  the  propulsion 
system  components.  Since  the  RPM  of 
acoustically  significant  machinery  is  very 
important  in  the  sonar  classification 
analysis  of  a  vessel,  the  model  must 
realistically  control  each  component's  RPM 
in  the  engine/shaft  drive  train. 


INSTRUCTOR  INTERFACE 


The  sonar  trainer  instructor  needs  to 
control  the  motion  of  the  various  vessels 
in  the  training  scenario.  This  is  done  by 
changing  the  ordered  speed,  course,  and 
depth  (if  applicable)  for  the  desired 
vessel.  When  new  ordered  values  are 
entered  by  the  instructor,  the  propulsion 
model  should  respond  realistically  to 
them.  However,  for  many  vessels  with 
multiple  propulsion  modes  available,  there 
is  not  always  a  unique  propulsion  mode 
defined  for  a  given  set  of  ordered  values. 
In  this  case,  the  instructor  might  (but 
not  always)  want  to  select  the  particular 
mode  that  is  desired  for  the  vessel. 


The  model  is  designed  to  calculate  a 
favorite  propulsion  mode  for  the  ordered 
speed  and  depth  of  the  vessel.  This  is  the 
most  probable  propulsion  mode  that  would 
be  used  for  the  ordered  speed  and  depth, 
and  therefore  acts  as  a  default  mode  for 
the  instructor. 

Availabls  Moda.  List 

The  model  also  generates  a  list  of 
available  modes  for  the  ordered  speed  and 
depth  of  the  vessel.  These  modes  are  all 
valid  at  the  ordered  speed  and  depth,  with 
some  more  likely  to  be  used  than  others  in 
reality.  For  example,  a  two  shafted  vessel 
can  run  with  one  or  two  propellers 
turning.  Typically  there  is  a  speed  range 
for  the  vessel  where  either  mode  is  valid 
(mode  overlap) .  If  the  ordered  speed  was 
in  this  speed  range,  then  both  modes  would 
be  in  the  available  mode  list  to  allow  the 
instructor  to  select  from  among  the 
options. 


V.' 


MODE  HIERARCHY 

A  structured  hierarchy  of  modes  and 
algorithms  is  used  to  control  the 
propulsion  model.  These  are  organized  as 
follows  from  the  highest  level  to  the 
lowest : 

1 .  Final  Mode 

2 .  Commanded  Mode 

3.  Ordered  Mode  List 

-1 .  Engine/Shaft  Configuration 
5.  Transition  Algorithms 

Figure  4.  illustrates  the  hierarchy  of 
these  modes  and  algorithms  as  well  as  the 
instructor  interface  modes  and  the  RPM 
adjustment  calculations. 
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Figure  4.  Mode  Hierarchy  Diagram 


This  modular  sequence  of  control  modes,  as 
will  be  shown  below,  allows  the  model  to 
be  both  generic  and  adaptable  to  different 
fidelity  requirements. 

Final  Mode 

The  instructor  can  select  the  desired 
propulsion  mode  from  among  the  available 
mode  list  or  accept  the  favorite  mode 
default.  The  mode  that  is  eventually 
selected  either  by  the  instructor,  or  by 
default,  is  referred  to  as  the  final  mode. 
It  is  this  mode  along  with  the  ordered 
speed  and  depth  that  will  trigger  the 
dynamic  behavior  of  the  propulsion  model. 
After  all  mode  transitions  are  concluded, 
then  the  vessel  will  remain  in  the  final 
mode.  Of  course,  it  is  quite  possible  that 
the  final  mode  will  be  the  same  as  the 
current  mode  in  which  case  there  will  be  a 
relatively  simple  transition  in  the  RPM  of 
the  engines  and  shafts. 
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In  some  types  of  vessels,  most  notably 
diesel  submarines,  it  is  possible  to 
select  a  propulsion  mode  for  a  particular 
ordered  speed  and  depth  that  cannot  be 
used  immediately.  For  example,  if  a  diesel 
sub  is  submerged  below  the  snorkle  depth 
and  the  final  mode  uses  a  diesel  engine  in 
one  of  its  configurations,  then  the  model 
cannot  start  a  transition  immediately 
since  the  engine  cannot  yet  be  used.  In 
this  case,  an  intermediate  mode  that  is 
valid  at  the  current  depth  is 
automatically  specified  as  the  commanded 
mode  before  the  final  mode  is  eventually 
used.  However,  for  most  cases  the 
commanded  mode  is  the  same  as  the  final 
mode . 


Using  the  commanded  mode  and  the  current 
propulsion  mode,  the  model  initializes  an 
ordered  mode  list  (see  Figure  5.).  This 
list  defines  a  sequence  of  modes  that  will 
be  used  by  the  transition  algorithms  and  a 
minimum  mode  duration  time  for  each 
ordered  mode.  The  last  mode  in  the  list  is 
always  the  commanded  mode.  This  mode  list 
is  designed  to  add  realism  for  complex 
mode  changes  where  a  vessel  would  not 
directly  transition  from  the  current 
propulsion  mode  to  the  commanded  mode,  but 
would,  instead,  switch  through  several 
transient  modes  before  finally  reaching 
the  commanded  mode.  This  is  an  important 
feature  to  prevent  unrealistic  transitions 
that  would  create  negative  training  in 
sonar  classification.  Note  that  if  the 
commanded  mode  is  not  the  same  as  the 
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Figure  5.  Ordered  Mode  '.1st  Table 


final  mode,  then  the  model  will  cycle 
through  two  ordered  mode  lists.  The  first 
will  be  for  the  intermeaiate  commanded 
mode  transition  and  the  second  will  be  for 
the  final  mode  transition. 

An  additional  important  feature  of  the 
ordered  mode  list  is  that  it  permits 
instructor  initiated  interruptions  of 
transitions  already  in  progress.  For 
example,  if  the  instructor  inputs  a  new 
set  of  orderea  values  for  a  vessel,  then  a 
mode  transition  will  be  initiated.  For 
some  types  of  vessels,  this  transition 
process  from  the  current  mode  to  the  final 
mode  will  take  tens  of  minutes  to 
complete.  During  this  period,  the 
instructor  may  decide  to  change  the 
ordered  values  for  this  vessel  again 
before  the  final  mode  has  been  reached.  If 
this  occurs,  then  a  new  transition  will 
start  using  the  last  mode  fetched  from  the 
ordered  mode  list  (as  the  current  mode) 
and  the  new  final  mode.  This  provides  a 
realistic  response  to  the  new  ordered 
values  since  the  transient  modes  in  the 
ordered  mode  list  are  all  equally  valid  as 
current  or  final  modes.  If  the  transient 
response  for  a  mode  change  was  simply 
described  in  detail,  then  it  would  be  very 
difficult  to  decide  in  the  model  what  the 
proper  response  should  be  if  new  ordered 
values  arrive  during  a  mode  change. 


Using  the  ordered  mode,  the  configuration 
for  each  engine/shaft  drive  train  is 
determined  (see  Figure  6.).  These  new 
configurations  are  called  the  ordered 
configurations  and  are  used  with  the 
current  configurations  (based  of  the 
current  propulsion  mode)  to  define  the 
engine/shaft  transition  algorithms  (see 
Figure  7.).  Each  engine/shaft  drive  train 
is  handled  independently  using  a  fixed  set 
of  25  transition  algorithms. 
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Figure  6.  Engine/Shaft  Configuration  Table 
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Figure  7.  Engine/Shaft  Algorithm  Table 


Transition  Algorithms 

Each  of  the  25  algorithms  consists  of  a 
series  of  engine  and  shaft  RPM  adjustment 
equations  and  if-then-else  logic 
statements.  There  are  a  total  of  seven 
equations  and  logic  statements  used  to 
form  the  elements  of  the  algorithms.  The 
largest  algorithm  uses  six  of  these 
equations  and  logic  statements.  Using  this 
simple  mechanization,  the  mode  transition 
dynamics  can  be  modeled  with  very  few 
basic  equations.  These  basic  equations 
directly  control  the  engine  and  shaft  RPMs 
and  are  generic  to  all  vessel  types.  Only 
the  coefficient  constants  of  the  equations 
are  unique  to  a  particular  vessel  type. 
These  characterizing  coefficients  are  a 
part  of  the  complete  set  of  coefficients 
which  specify  a  vessel  type,  and  are 
defined  and  fine  tuned  by  the  training 
instructors.  Coefficients  are  changed 
during  non- instructional  sessions  whenever 
new  information,  such  as  from  at-sea 
experience,  is  available,  or  as  other 
realism  considerations  suggest  the  need. 

Engine/Shaft  RPM  Calculations 

The  engine  and  shaft  RPMs  are  adjusted 
using  simple  digital  exponential  time 
response  filters  of  the  form: 

rpm(n+l)=  ( 1— K ) * (ordered  RPM)  +  K*rpm(n) 

where  K=  time  constant  coefficient, 

n=  last  computational  iteration, 
n+l=  this  iteration 

The  ordered  RPM  is  calculated  from  the 
ordered  speed  and  the  vessel's 
turns-per-knot  value  which  is  based  on  the 
ordered  configurations.  The  filter 
prevents  discontinuities  in  the  RPM  of  the 
shaft  or  engine  when  new  ordered  values 
are  received.  It  also  realistically  models 
the  mechanical  inertia  of  the  rotating 
machinery  since  they  can  respond  only  so 
fast  to  a  new  RPM  setting. 


The  generic  propulsion  model  modifies  the 
calculated  values  for  the  engine  and  shaft 
RPM  to  simulate  such  effects  as  long  teim 
RPM  wander,  turn  count  masking,  sea  state 
RPM  instability,  and  shaft  bowing 
(inboard/outboard  RPM  differential)  in 
turns.  Each  of  these  effects  is  modeled  to 
add  realism  to  new  maneuvers  of  a  vessel. 
Some  of  these  clues,  such  as  shaft  bowing, 
are  very  important  to  sonar  operator 
training  since  they  help  predict  the 
position  or  motion  of  a  vessel  from  its 
acoustic  signature.  The  model  also 
includes  the  singing  propeller  effect,  a 
distinct  tonal  characteristic,  which  can 
be  very  intense  acoustically  when  it 
occurs . 

SONAR  SIGNAL  STIMULATION 

The  14E27A  sonar  trainer  consists  of  two 
primary  sections,  the  actual  ship  sonar 
equipment  and  a  hardware  sonar  signal 
stimulator.  The  stimulator  produces  the 
actual  electrical  waveforms  like  those 
normally  produced  by  the  hydrophone  or 
sonobuoy  sensors.  These  simulated 
waveforms  then  drive  the  actual  sonar 
equipment  based  on  the  results  of  various 
models  in  the  trainer.  The  signal  used  to 
stimulate  the  sonar  equipment  consists  of 
two  main  components,  tonal  and  broadband. 

Tonal  Stimulation 

The  tonal  signal  for  a  particular  vessel 
as  received  by  the  actual  sonar  equipment 
consists  of  many  different  spectral 
components.  As  described  earlier,  these 
"line"  components  (as  seen  on  a  spectrum 
analyzer)  are  produced  by  engines, 
propellers,  motors,  and  other 
miscellaneous  ship  equipment.  A  particular 
piece  of  equipment  may  produce  a  single 
line,  or  it  may  generate  a  harmonically 
related  set  of  lines.  This  effect  is 
created  in  the  14E27A  sonar  trainer  by  the 
use  of  hardware  line  family  generators. 
The  line  family  generator  allows  the 
software  to  specify  the  frequency,  line 
width,  and  amplitude  of  a  single  line  or  a 
group  of  harmonic  lines.  The  RPM  of  the 
engine  and  shaft  along  with  the  propulsion 
mode  are  used  to  calculate  the  parameters 
for  the  line  families. 

Broadband  Stimulation 

The  broadband  signal  for  a  particular 
vessel  consists  primarily  of  flow  noise 
and  propeller  cavitation.  The  flow  noise 
calculation  is  usually  based  on  the 
vessel’s  speed.  The  propeller  cavitation 
calculation  uses  the  propeller  RPM  to 
determine  if  cavitation  is  occurring. 
Using  these  propulsion  model  outputs,  the 
broadband  signal  generator  parameters  are 
selected  to  simulate  the  desired  vessel. 


SHIP  MOTION 

The  generic  propulsion  model  is  also  used 
to  compute  parameters  for  the  ship  motion 
model  in  the  14E27A  trainer.  This  model  is 
used  to  compute  the  position  of  all 
vessels  in  the  training  scenario.  Since 
the  new  position  of  a  vessel  is  dependent 
on  the  thrust  from  the  propulsion  system, 
the  ship  motion  model  needs  to  receive 
this  dynamic  data  from  the  propulsion 
model.  While  some  inputs  such  as  the  turn 
rate  control  of  the  vessel  are  handled 
directly  by  the  motion  model,  other  inputs 
such  as  the  depth  control  of  the  vessel 
are  used  by  both  the  motion  and  propulsion 
models. 

The  motion  model  will  compute  a  root  mean 
square  RPM  for  all  of  the  actively  turning 
propellers  and  then  compute  a  new  vessel 
speed  by  using  the  turns-per-knot  value 
and  the  mean  RPM  value.  This  allows  the 
ship  to  respond  in  a  realistic  fashion  to 
changes  in  the  propulsion  of  the  ship.  For 
example,  if  the  propeller  RPM  increases 
then  the  vessel  will  gradually  speed  up 
until  it  reaches  the  desired  speed.  In 
general,  the  vessel's  motion  will  lag  the 
propulsion  changes  due  to  the  vessel's 
inertia. 

MODEL  MODIFICATIONS 

One  of  the  most  important  features  of  the 
generic  propulsion  model  is  the  ease  with 
which  modifications  can  be  made  to  the 
vessel  types.  Since  all  vessel  unique 
parameters  are  organized  as  tables  of 
constants,  it  is  very  easy  to  fine  tune 
the  fidelity  of  a  particular  vessel  type 
by  altering  these  tables.  For  example,  it 
may  become  known  that  a  particular  vessel 
type  will  not  transition  directly  between 
propulsion  mode  3  and  mode  5,  but  will 
instead  transition  through  an  intermediate 
mode  7 .  This  enhancement  can  be  included 
by  simply  adding  mode  7  to  the  ordered 
mode  list  for  the  mode  3  to  5  transition 
element.  All  of  the  proper  responses  will 
then  occur  in  the  subsequent  control  logic 
for  this  new  enhancement. 

A  new  vessel  type  can  be  added  to  the 
system  by  creating  a  whole  new  set  of 
parameter  tables  and  then  adjusting  the 
constants  until  the  desired  fidelity  level 
is  achieved.  If  the  new  vessel  type  is 
similar  to  an  existing  type,  then  it  is 
possible  to  copy  the  existing  vessel 
type's  data  tables  to  the  new  vessel  type 
and  then  make  the  desired  modifications. 
This  is  useful  where  the  new  vessel  type 
may  only  have  a  slight  but  important 
acoustic  difference  from  a  previous  vessel 
type.  This  occurs  frequently  in  submarines 
where  a  new  production  run  of  a  given 
submarine  class  will  sound  slightly 
different  that  others  in  the  same  class. 


CONCLUSIONS 

The  generic  propulsion  model  has  been 
shown  to  possess  several  technical  and 
cost  advantages  over  the  traditional 
approach  of  simulating  each  vessel  type 
with  a  unique  model.  It  also  allows  the 
instructor  to  fine  tune  the  acoustic 
signature  fidelity  of  the  vessel  types  to 
the  desired  level.  The  generic  propulsion 
model's  structure  has  been  demonstrated  as 
being  adaptable  to  new  vessel  types  and 
allows  enhancements  to  existing  types. 
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ABSTRACT 

A  videodisc-based  driving  procedures  training  system  is  under  development  by  General  Dynamics  Electronics 
Division  for  the  United  States  Marine  Corps  that  will  provide  training  for  drivers  of  the  new  LVT-7A1  tracked 
landing  vehicle.  This  new  system,  to  be  delivered  in  March  of  1984,  will  provide  training  and  practice  to  new 
drivers  in  correct  vehicle  operation  before  they  drive  an  actual  vehicle.  The  system  is  designed  to  train  750 
students  each  year  in  classes  of  30  students  each.  The  LCDT  consists  of  a  minicomputer  with  a  master  control 
console,  five  instructor  consoles,  and  five  student  stations  that  replicate  the  driver's  compartment  of  the 
LVT-7  At, 


INTRODUCTION 

The  LVT-7 A1  is  an  upgraded  version  of  a  previous 
Marine  Corps  Tracked  Landing  Vehicle  put  in  service  in 
1971.  The  significant  portions  of  the  upgrade  include  a 
new  engine  and  transmission,  as  well  as  a  new  instrument 
panel  and  other  mechanical  changes.  The  principal  use  of 
the  vehicle  is  transporting  troops  or  cargo  from  a  landing 
ship  stationed  off-shore  to  the  beach  with  minimum  risk. 

In  this  application,  the  vehicle  carries  25  troops  and  a 
crew  of  three.  In  an  effort  to  reduce  the  high  mainte¬ 
nance  costs  caused  by  the  failure  of  vehicle  drivers  to 
follow  correct  operating  procedures,  a  driving  procedures 
simulator  is  being  developed  by  General  Dynamics 
Electronics  Division  for  delivery  in  March  of  1984. 

The  major  purpose  of  the  trainer  is  to  train  new 
drivers  in  proper  vehicle  operating  procedures.  The 
trainer  will  be  used  in  conimetion  with  classroom  instruc¬ 
tion  and  actual  vehicle  driving  periods  and  will  train 
750  students  each  year  in  classes  of  30  students  each.  It 
is  not  intended  to  replace  actual  vehicle  driving  time,  but 
to  train  for  normal  as  well  as  emergency  and  failure 
shutdown  procedures  that  must  be  followed  to  prevent 
compound  vehicle  damage.  These  procedures  can  not  be 
taught  effectively  in  the  classroom  due  to  lack  of  real- 
world  conditions,  or  on  the  vehicle  because  of  the 
potential  danger  to  vehicles  or  personnel. 

The  major  components  of  the  training  system  are  the 
simulation  computer  and  the  five  trainee  stations  with 
associated  instructor  stations.  Figure  lisa  block 
diagram  of  the  overall  training  system. 

The  simulation  computer  is  a  low-cost  minicomputer 
of  the  SEL  32/27  type  which  contains  and  executes  the 
software  that  runs  and  controls  the  training  system.  The 
computer  system  consists  of  the  central  processor,  and 
80  MB  removable  media  disc  drive,  a  tape  unit  for  system 
rebuild  and  program  archival  use,  a  200  CPS  printer,  and  a 
master  control  terminal. 

The  computer  software,  written  in  FORTRAN  77,  is 
the  result  of  over  four  man-years  of  development.  It 
simulates  the  vehicle  responses  by  modeling  vehicle 


dynamics  including  engine,  transmission,  braking, 
steering,  and  traction  as  a  result  of  student  inputs  and 
vehicle  operating  environment.  The  instructor  has  the 
option  of  changing  the  operating  environment  by 
specifying  the  simulated  outside  temperature  or  by 
introducing  vehicle  malfunctions  at  particular  locations 
during  the  training  session.  The  procedures  to  be  followed 
by  the  student  for  the  various  driving  conditions  as  well  as 
those  to  be  followed  under  malfunction  conditions  are 
monitored  by  the  computer  software  for  later  review  and 
print  out  by  the  instructor,  if  desired.  Student 
performances  that  are  monitored  include  the  number  of 
times  the  student  exceeds  the  maximum  speed  in  a  gear, 
the  number  of  stalls,  the  number  of  times  the  vehicle  is  in 
the  wrong  operating  mode,  and  others  for  a  total  of 
16  parameters. 

The  five  student  stations  replicate  those  controls  and 
gauges  in  the  driver's  station  that  are  critical  to  the 
correct  operation  of  an  actual  vehicle.  These  controls 
include  the  steering  wheel,  gear  selector,  hand  and  foot 
throttle,  water/land  mode  selector  switch,  cold-start 
switch,  and  ramp  control  handle.  Figure  2  is  a  diagram  of 
the  student  enclosure.  The  various  gauges  include  the 
transmission  oil  temperature  and  pressure,  engine  oil 
temperature  and  pressure,  engine  water  temperature,  air 
filter  restriction,  battery  voltage,  engine  RPM,  vehicle 
speed,  and  compass  heading.  Figure  3  shows  the  vehicle 
control  panel.  The  fire  warning  and  fire  suppression 
system  is  also  simulated  so  that  the  student  can  receive 
instruction  in  vehicle  fire  procedures. 

Each  student  station  also  has  a  voice  and  vehicle 
sound  synthesis  system.  The  voice  synthesis  system  will 
command  the  student  in  much  the  same  way  as  an  actual 
training  instructor  using  voice  commands  for  such  things 
as  'Take  the  right  fork",  "Stop  the  vehicle",  "Enter  the 
water",  and  "Return  to  the  beach".  The  voice  synthesis 
system  is  completely  solid-state  and  can  play  hack  up  to 
64  seconds  of  prerecorded  voice  commands.  The  sound 
synthesis  system  reproduces  the  various  vehicle  sounds 
necessary  for  training  including  the  engine,  transmission, 
bilge  pumps,  personnel  ramp,  water  jets,  and  tracks  for  a 
total  of  1 5  sounds,  all  under  computer  control  and 
coordinated  with  the  student  actions. 
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Figure  2.  Realism  Is  an  Important  Objective  in  the  Trainee  Station 


Figure  3.  LVT-7A1  Control  Panel 


Another  part  of  the  student  station  is  the  visual 
system  which  shows  the  student  pictures  of  the  driving 
course  on  a  6.5-foot-diagonal  projection  TV  screen.  The 
source  of  the  pictures  is  a  videodisc  that  was  produced 
expressly  for  the  training  system  as  part  of  the  project. 
The  videodisc  is  played  back  on  an  industrial-quality 
player  under  computer  control.  The  video  from  the  disc  is 
processed  by  the  visual  electronics  hardware  under 
computer  control  to  generate  a  modified  video  image  that 
shows  the  results  of  the  student's  steering  the  vehicle  to 
the  left  or  right  of  the  correct  course.  The  speed  of  the 
video  presentation  is  controlled  by  the  computer  in 
response  to  student  manipulation  of  the  throttle,  gear 
selector,  and  brake.  The  visual  screen  also  shows 
computer-generated  advisory  messages  and  instructions  to 
the  student. 


Associated  with  each  student  station  is  the 
instructor's  console  which  is  a  standard  computer  terminal 
connected  to  the  trainer  computer  via  serial  link. 

The  audio,  visual,  and  procedure  monitoring  portions 
of  the  trainer  will  be  discussed  in  greater  detail  in  the 
following  paragraphs. 

AUDIO  SUBSYSTEM 

As  described  previously,  the  audio  subsystem  is 
responsible  for  generating  the  voice  commands  and  the 
vehicle  sounds  sent  to  the  student  as  feedback  for  his 
actions.  Figure  4  is  an  overall  block  diagram  of  the  sub¬ 
system.  The  voice  commands  are  the  same  as  those  which 
would  be  given  by  an  instructor  training  the  student. 
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Figured  Audio  Subsystem 


These  commands  must  be  easy  to  understand  and  natural 
sounding  for  effective  training.  To  generate  these  voice 
commands,  an  instructor  speaks  the  desired  commands 
into  the  speech  digitization  hardware.  This  hardware 
converts  the  speech  into  digital  data  using  the 
Continuously  Variable  Slope  Delta  Modulation  (CVSDM) 
technique  at  a  clock  rate  of  16  kHz  with  an  input  low-pass 
filter  cutoff  frequency  of  5  kHz.  The  digitized  speech  is 
then  saved  on  disc  for  later  use.  At  the  start  of  the 
training  lesson,  this  speech  data  is  sent  from  the  trainer 
computer  to  each  individual  student  station  for  use  during 
the  training  lesson,  and  is  stored  in  solid-state  dynamic 
memory.  When  a  voice  command  is  required,  the  trainer 
computer  sends  a  command  to  the  student  station  that 
defines  which  voice  command  to  speak.  The  voice  hard¬ 
ware  then  converts  the  digitized  voice  data  back  into 
natural-sounding  speech  and  sends  it  to  the  trainee 
through  his  headset. 

The  sound  synthesis  subsystem  must  reproduce  the 
simulated  vehicle  sounds  in  a  correct  and  realistic  manner 
because  they  are  cues  to  the  trainee  indicating  correct  or 
incorrect  vehicle  operation.  These  sounds  include  the 
engine  as  it  is  started  under  normal  and  freezing  condi¬ 
tions,  as  it  runs  under  various  loads  and  speeds,  and  as  it 
stops.  The  transmission  sounds  that  mist  be  generated 
include  the  sounds  in  each  of  the  four  forward  and  two 
reverse  speeds.  Other  vehicle  sounds  that  must  be 
generated  are  the  engine  cooling  fan,  plenum  doors 
opening  and  closing,  ramp  raising  and  lowering,  ramp 
hitting  deck,  hydraulic  and  electric  bilge  pumps,  audio 
warning  tone,  water  jet  noise,  and  track  noise.  The  mal¬ 
function  sounds  that  are  simulated  include  engine  over¬ 
heating  with  radiator  hissing  sound  and  the  transmission 
gears  grinding. 

The  sounds  are  generated  using  16  commercially 
available  sound  generator  ICs.  Each  IC  can  generate 
three  individually-controlled  frequencies  with  noise  and  a 
modulation  function.  The  outputs  of  several  ICs  are 
mixed  together  and  filtered  to  form  more  complicated 
sounds.  The  most  complicated  sound,  the  engine,  requires 
six  frequencies,  two  modulation  functions,  and  two  noise 
components  to  duplicate  the  actual  vehicle  sound.  The 
least  complicated  sound,  the  hissing  sound  from  the 
radiator,  requires  only  a  single  noise  component.  The 
software  in  the  trainer  computer  monitors  the  simulated 
vehicle  operating  conditions  and  outputs  the  control  words 
to  the  sound  synthesis  system  which  defines  the  actual 
frequencies  and  amplitudes  to  be  generated  by  each  IC. 

Since  the  vehicle  sounds  are  such  an  important  feed¬ 
back  cue  to  the  student,  it  is  necessary  that  they  be  as 
correct  as  possible.  The  first  step  in  the  sound  synthesis 
process  is  recording  the  actual  vehicle  sounds.  This  was 
accomplished  by  recording  a  vehicle  under  known 
operating  conditions.  These  conditions  were  chosen  to 
isolate  and  reduce  interaction  between  sounds  to  the 
greatest  extent  possible.  First,  the  sounds  that  are 
independent  of  the  engine  operating  such  as  the  horn, 
ramp  opening  and  closing,  ramp  hitting  deck,  bilge  pump, 
and  starter  motor  were  recorded  on  a  high-quality  tape 
recorder  located  near  the  sound  source.  The  absolute 
amplitudes  of  these  sounds  were  then  recorded  using  a 
sound-level  meter  at  the  driver's  station.  The  same  pro¬ 
cedures  were  followed  for  the  sounds  of  the  engine 


running  at  various  RP Ms,  but  with  the  vehicle  stationary. 
The  procedures  were  again  followed  for  the  engine  cooling 
fan  and  the  plenum  door  opening  and  closing.  Finallv,  the 
vehicle  was  driven  over  actual  terrain  to  record  and 
measure  the  sounds  of  the  transmission  in  the  various 
gears,  as  well  as  the  track  and  the  water  jet  sounds. 

The  recordings  of  these  sounds  were  then  digitized, 
stored  on  a  magnetic  disc,  and  analyzed  using  an  FI  T 
analysis  program  which  extracted  the  principal  frequency 
components.  These  frequency  values  were  then  used  as 
inputs  to  a  sound  development  program  which  reproduced 
the  sounds  using  the  sound  synthesis  ICs.  These  synthe¬ 
sized  sounds  were  then  compared  to  the  actual  sounds 
using  audio  analysis  techniques.  The  more  complicated 
engine  sound,  which  had  several  components  that  changed 
as  a  function  of  engine  RPMs,  was  analyzed  at  several 
recorded  RPMs  to  determine  the  relationship  between  the 
amplitude  and  the  frequency  of  the  components.  Once 
this  relationship  was  determined,  the  sounds  at  the 
intermediate  RPMs  could  be  determined  so  that  a 
continuous  spectrum  of  sounds  can  be  generated  during 
the  training  session.  Sound  generation  in  the  trainer 
required  that  the  software  generate  the  various  data 
words  required  by  the  sound  synthesis  system  so  that  the 
sounds  would  be  correct  and  natural. 

VISUAL  SUBSYSTEM 

The  visual  subsystem  is  responsible  for  providing  the 
scenes  of  the  driving  course  that  match  the  operation  of 
the  simulated  vehicle  by  the  trainee.  To  add  realism  and 
acceptance  by  the  students,  the  visual  system  provides  a 
simple  interactive  steering  approach  that  keeps  the 
student  busy  during  the  simulated  driving  so  that  mal¬ 
functions  are  not  the  only  thing  that  the  student  must 
respond  to.  The  major  components  of  the  visual  system 
are  the  videodisc  player  and  videodisc,  the  visual  elec¬ 
tronics,  and  the  projection  TV  system.  Figure  5  is  a  block 
diagram  of  the  visual  subsystem. 

The  visual  subystem  uses  a  videodisc  to  store  the 
visual  scenes.  There  are  four  different  types  of  driving 
situations  portrayed  on  the  videodisc:  stall  test,  land 
driving,  water  driving,  and  surf  operations.  The  stall  test 
is  a  simple,  straight-ahead  driving  sequence  that  is  part  of 
the  preoperational  tests  on  the  vehicle  each  day.  As  part 
of  the  training,  the  instructor  can  select  the  normal  stall 
test  or  the  stall  test  that  simulates  and  shows  a  vehicle 
fire  in  the  engine  compartment.  The  land  driving  portion 
is  a  3.6-mile  sequence  that  requires  the  student  to 
demonstrate  correct  operation  of  the  engine,  transmis¬ 
sion,  steering,  and  brake  as  the  vehicle  is  driven  over 
various  types  of  terrain.  As  part  of  this  sequence,  the 
student  must  also  follow  the  hand  signals  given  by  a 
ground  guide.  The  water  driving  portion  requires  that  the 
student  demonstrate  correct  water  operating  procedures 
including  water  entry  and  exit  as  well  as  turns,  stopping, 
and  backing  up  in  the  water  while  operating  the  vehicle  in 
a  protected  jetty  area.  This  sequence  also  requires  that 
the  student  follow  a  more  complicated  set  of  ground- 
guide  hand  signals  and  maneuvers.  The  surf  operatioas 
portion  is  a  six-minute  sequence  that  exposes  the  student 
to  the  conditions  and  procedures  required  when  entering 
and  leaving  the  surf  from  the  beach.  The  sequence  starts 
on  the  beach,  goes  through  the  surf  zone,  turns  parallel  to 


visual 

ELECTRONICS 


VISUAL  SUBSVSTE M _ 

COMPUTER  SIMULATION 


AUK346 


Figure  5.  Visual  Subsystem 
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the  beach  for  about  100  meters,  and  returns  to  the  beach 
through  the  surf  zone. 

The  quality  production  of  these  sequences  was  impor¬ 
tant  to  the  acceptance  of  the  trainer  by  the  instructors 
and  the  students.  Both  film  and  video  were  used  to  take 
the  pictures  of  the  various  scenarios.  The  land  portions 
were  filmed  using  a  35 -mm  step-frame  camera  that  was 
connected  to  a  speedometer  output  shaft  on  the  right- 
hand  track.  A  new  frame  of  film  was  taken  whenever  the 
vehicle  went  1.5  feet  forward,  thus  providing  a  maximum 
simulated  vehicle  speed  of  30  mph  when  the  film  is  con¬ 
verted  to  video  on  a  videodisc.  The  use  of  the  freeze- 
frame  capability  of  the  videodisc  allows  the  trainee  to  go 
as  fast  or  as  slow  as  desired  and  still  provide  a  correct 
visual  presentation.  The  water  sequences  were  shot  using 
video  since  there  is  no  distance- traveled  indication  to 
control  the  film  camera.  However,  the  sequences  were 
shot  using  a  constant,  known  engine  RPM  so  that  the 
simulation  program  would  have  a  reference  from  which  to 
speed  up  or  slow  down  the  videodisc  to  portray  the 
student's  actual  speed. 

The  two  cameras  were  mounted  on  a  specially- 
constructed  camera  mount  which  was  welded  to  an  actual 
vehicle  just  ahead  of  the  driver’s  station  so  the  same 
relative  view  would  be  retained  in  the  simulator.  The 
focal  lengths  and,  thus,  the  angles  that  each  camera 
covered  were  set  to  be  the  same  and  to  match  the  field  of 
view  that  would  be  portrayed  from  the  trainee's  position 
onto  the  projection  TV  system. 

The  visual  electronics  system  has  three  purposes. 

The  first  is  to  provide  the  interface  between  the  trainer 
computer  and  the  videodisc  player.  The  second  is  to  pro¬ 
vide  the  interactive  steering  capability.  The  third  is  to 
generate  warning  and  advisory  messages. 

The  data  from  the  trainer  computer  provides  the 
controlling  information  for  the  videodisc  player  and  tells 
it  to  search  to  a  particular  video  frame,  to  step  forward 


or  back  to  the  next  frame,  or  to  play  the  disc  at  norma) 
speed.  The  interface  electronics  formats  the  data  re¬ 
ceived  from  the  trainer  computer  and  sends  the  data  to 
the  videodisc  player.  The  electronics  also  reports  video¬ 
disc  player  status  information  to  the  trainer  computer. 

Implementation  of  the  interactive  portion  of  the 
visual  electronics  system  requires  that  data  be  recorded 
that  defines  the  direction  that  the  camera  system  was 
pointing  at  the  instant  the  picture  was  taken.  It  is  also 
desirable  to  record  the  inclination  of  the  vehicle  so  that 
the  simulation  program  would  know  when  the  vehicle  was 
going  up  or  down  a  hill  to  accurately  simulate  the  vehicle 
speed  and  sounds  during  a  training  session.  This  data 
logging  took  place  during  filming  by  using  vertical  and 
heading  gyros  from  an  aircraft  navigation  system.  The 
readings  of  these  gyros  were  converted  to  digital  data  as 
the  pictures  were  taken  and  were  recorded  on  each  film 
frame  and  each  video  frame  in  the  active  image  area. 
When  the  film  and  video  are  put  on  a  videodisc  and  later 
played  back,  special  circuits  in  the  visual  electronics  will 
recover  the  data  and  send  it  to  the  simulation  program  for 
incorporation  into  the  vehicle  model  solution.  This 
method  eliminated  the  need  for  the  training  program  to 
store  and  retrieve  data  that  describes  the  course  heading 
and  grade  for  each  video  frame.  Any  scenerio  changes  in 
the  driving  course  that  might  have  rquired  a  change  in  the 
course  data  were  handled  automatically  by  the  editing 
process  since  this  data  was  actually  part  of  the  film  or 
video.  The  data  recorded  was  12  bits  of  heading  data  for 
a  resolution  of  0.079  degrees  and  8  bits  of  inclination 
angle  information  for  a  resolution  of  0.351  degrees. 

Figure  6  shows  the  location  of  the  data  bits  within  the 
active  video  area.  This  portion  of  the  picture  is  blanked 
so  that  it  is  not  visible  to  the  student. 

The  interactive  steering  portion  of  the  visual  elec¬ 
tronics  receives  trainee  steering  error  data  from  the 
trainer  computer  and  uses  this  data  to  rotate  the  visual 
scene  from  the  videodisc  right  or  left,  depending  on  the 
error  made.  When  the  student's  error  is  large  and  the 
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Figure  6.  Data  Bits  in  the  Film  or  Video  Frame 

amount  of  rotation  is  such  that  there  is  no  data  from  the 
videodisc  for  the  scene,  the  visual  electronics  generates 
synthetic  video  for  that  portion  not  on  the  videodisc. 
Figure  7  shows  the  shifting  scene  and  the  computer¬ 
generated  color  when  the  shift  amount  is  large.  Thus,  as 
the  student  drives  around  the  course,  the  correct  path 
must  be  driven  and  maintained  or  the  scene  will  shift  off 
the  screen  in  the  direction  of  the  error  made  and  the 


student  will  see  nothing  but  synthetieallv-generated  color. 
This  shifting  is  accomplished  by  synchronizing  to  the 
video  from  the  videodisc,  generating  new  svnc  signals  that 
are  shifted  from  the  incoming  signals  an  amount 
determined  by  the  student's  steering  error,  combining 
these  with  the  incoming  video  to  generate  the  new  shifted 
video,  and  sending  these  to  the  projection  TV  system. 
Figure  8  is  a  block  diagram  of  the  visual  electronics 
portion  of  the  system.  The  visual  electronics  system  also 
generates  computei^controlled  warning  and  advisory 
messages  and  sends  them  to  the  projection  TV  for  display. 

The  various  driving  scenes  and  messages  are  shown  on 
a  commercially- avail  able,  high-brightness,  6.5-foot- 
diagonal-screen  projection  TV  system  that  is  eight  feet 
away  from  the  trainee's  position.  To  provide  the  student 
with  a  straight-on  view  of  the  screen  while  maintaining 
the  correct  student- to-screen  distance  required  that  the 
optical  path  be  folded  using  a  flat  mirror  and  that  the 
image  from  the  projection  TV  system  be  reversed  elec¬ 
tronically. 

DRIVING  PROCEDURE  MONITORING 

Monitoring  the  student’s  driving  procedures  is  an 
important  part  of  the  training  program.  The  goal  of  the 
training  school  is  to  graduate  drivers  from  the  program 
who  have  knowledge  of  and  are  able  to  demonstrate  the 
correct  vehicle  driving  procedures.  To  grade  the  students 
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Figure  7.  Examples  of  Scene  Rotations 
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Figure  8.  Visual  Electronics  Detailed  Block  Diagram 


on  their  performance,  the  computer  program  must  know 
the  correct  procedures  to  use  as  a  standard.  It  would  also 
be  desirable  for  the  training  course  instructors  to  be  able 
to  make  changes  to  the  driving  procedures  monitored  by 
the  program  so  that  any  changes  in  the  actual  vehicle 
operating  procedures  would  be  reflected  in  the  simulated 
driving  course.  To  accomplish  these  two  goals,  an  English 
Language  procedure  file  system  was  developed  that  ex¬ 
pressed  the  actions  to  be  performed  by  the  student  in  real 
vehicle  terms  and  conditions.  Thus,  anyone  familiar  with 
the  operation  of  the  actual  vehicle  could  read  the  pro¬ 
cedure  file  to  determine  if  the  actions  and  responses  were 
correct  without  having  knowledge  of  computer  program¬ 
ming.  Any  changes  to  the  procedures  are  simply  entered 
by  modifying  the  procedure  file  using  a  text  editor.  This 
procedure  file  is  then  read,  parsed,  and  analyzed  by  the 
monitoring  program  during  the  course  of  the  training 
session  to  test  the  correctness  of  the  student's  actions  and 
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Figure  9.  Partial  Engine  Start  Procedure  File 


performance.  Since  the  procedure  file  read  and  changed 
by  the  course  instructor  is  the  same  as  that  used  by  the 
program  to  monitor  student  performance,  there  can  be  no 
translation  errors  between  the  desires  of  the  instructor 
and  the  student's  actions  checked  by  the  program. 
Figure  9  is  an  example  of  the  engine  start  procedure  file 
for  normal  temperature. 

CONCLUSIONS 

When  installed  in  March  of  1984,  the  LCDT  will 
provide  the  desired  procedures  training  on  the  LVT-7A1 
vehicle  for  the  Marine  Corps. 

The  technology  used  in  this  driver  trainer  is  directly 
applicable  to  other  vehicles  that  require  driving  procedure 
training. 
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. '  MERCHANT  SHIP  SIMULATORS 

Max  H.  Carpenter 
Special  Projects  Director 

Maritime  Institute  of  Technology  &  Graduate  Studies 
5700  Hammonds  Ferry  Road 
Linthicum  Heights,  Maryland  21090 

As  recently  as  14  years  ago,  the  various  tasks  involved  with  sailing  merchant 
ships  was  reviewed  and  emphasis  was  placed  on  those  considered  appropriate  for 
simulator  training.  Following  this  move,  development  was  started  by  several  organi¬ 
zations  throughout  the  world  on  ship  simulators.  This  paper  presents  the  story  of  the 
work  that  led  up  to  the  completion  of  two  large  ship  simulators.  The  size  of  these 
simulators  plus  motion  to  simulate  heavy  weather  and  a  360°  horizontal  field  of  view 
led  to  many  interesting  design  experiences.  The  problems,  errors  and  successes  that 
were  encountered  during  the  design,  development  and  final  construction  of  these  devices 
should  be  of  importance  to  future  planners  of  marine  simulators.  The  mathematical 
modeling  of  ship  and  systems  is  of  importance.  Decisions  concerning  the  bridge 
instrumentation,  performance  measurement,  and  instructor  control  are  based  on  training 
requirements.  Of  maximum  importance  is  the  visual  input  to  the  trainee.  The  fidelity 
of  the  simulator  is  judged  by  this  presentation. 


1.  Introduction 

The  Merchant  Marine  Industry,  obvi¬ 
ously  a  senior  service,  has  for  centuries, 
been  a  major  mode  of  heavy  goods  trans¬ 
portation.  Yet  this  important  industry 
was  the  last  to  make  use  of  computer- 
driven  simulation  for  training. 

Epic  changes  in  the  seafaring  indus¬ 
try  during  the  past  twenty-five  years 
demanded  the  implementation  of  innovative 
training  techniques.  Today's  deck  officer 
commands  ships  ten  times  and  more  the  size 
of  yesteryear's  vessels.  One  natural  gas 
carrier  is  capable  of  providing  the  aver¬ 
age  city  with  energy  for  months.  The 
increased  risk  in  terms  of  lives,  effects 
on  environment  and  capital  loss  is  much 
greater  than  ever  before.  These  high 
technology  vessels  call  for  a  wide  array 
of  new  and  specialized  shiphandling  and 
safety  techniques,  which  impose  new 
demands  and  responsibilities  on  the  ship's 
officer.  Traditional  onboard  methods  of 
training,  accumulated  with  years  of 
experience,  must  to  some  extent,  be  laid 
to  rest.  The  high  quality  training  now 
required  must  be  accomplished  by  real¬ 
time  computer  simulation.  This  need  was 
dramatically  demonstrated  during  the 
early  1950 's  when  radar  proved  to  be  less 
than  useful  and  sometimes  dangerous 
because  of  operator  error.  It  was  at 
this  moment  that  simulators  began  their 
slow  move  toward  acceptance  by  the  mari¬ 
time  industry.  These  early  simulators 
provided  training  ashore  and  afloat 
covering  what  turned  out  to  be  the  most 
important  use  of  radar,  its  ability  to 
provide  information  for  collision  avoid¬ 
ance.  The  first  rudimentary  attempts  of 
radar  simulation  rapidly  grew  to  an 
industry  which  is  now  well  entrenched  and 
providing  excellent  training  equipments. 

It  is  inconceivable  that  any  one  should 
be  sailing  today  without  adequate  radar 
training.  In  fact,  the  U.S.  law  so- 
states  that  you  must  have  an  endorsement 
on  your  license  as  a  radar  observer  on  a 
periodic  basis. 


2.  Background 

The  first  really  "exciting"  period  in 
maritime  simulation  began  not  with  com¬ 
plicated  electronic  simulation,  but 
what  could  be  described  as  small  boats, 
it  was  ascertained  during  experiments  at 
Grenoble,  France  that  an  accurately  scale 
down  version  of  any  specific  vessel  would 
in  fact,  render  very  satisfactory  results 
for  training  in  handling  that  particular 
vessel.  These  experiments,  which  eventu¬ 
ally  led  to  regular  courses  being  offered 
in  these  small  boats,  were  the  precursor 
of  the  more  complicated,  more  exotic 
ship  simulators  that  we  know  today. 
Obviously,  there  were  deficiencies  to  the 
Grenoble  type  of  training.  For  example, 
it's  impossible  to  scale  time.  (I  am 
sure  that  as  we  age,  we  would  all  like  to 
slow  it  down).  Therefore,  the  length  of 
time  it  takes  to  complete  a  maneuver  using 
these  model  vessels  is  drastically  reduced 
compiled  to  the  quarter  million  ton  tanker 
or  bu  r  that  you  are  attempting  to 
mimic.  Another  disadvantage  was  you  could 
never  accurately  repeat  any  particular 
exercise  or  event  so  that  you  could 
clinically  study  it  for  possible  improve¬ 
ments.  Further,  it  was  difficult  to  grade 
the  students,  and  instructor  opinion  form¬ 
ed  the  basis  for  evaluation.  While  the 
Grenoble  facility  and  others  like  it  are 
still  providing  valuable  training,  the 
limitations  outlined  did,  in  part,  influ¬ 
ence  the  move  toward  computer-driven 
simulation . 
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were  in  time  and  quality  an  accurate  rep¬ 
resentation  of  the  ship. 

These  early  simulators,  while  a  break 
through  in  the  state  of  the  art,  had 
limiatations .  One  of  their  obvious  de¬ 
ficiencies  was  a  poorly  defined  visual 
scene.  The  visual  technique  the  Dutch 
chose  to  use  was  a  point  light  source.  In 
this  system,  the  point  light  source 
illuminated  a  three-dimensional  model 
board  which  produced  a  shadow-like  image 
on  the  screen  that  resembled  an  approach 
to  a  port.  The  model  board  rotated  back 
and  forth  as  the  heading  of  the  vessel 
changed.  To  simulate  range  change,  the 
model  board  moved  in  and  out  with  respect 
to  the  point  light  source.  This  technique 
provided  a  wide  field  of  view,  however, 
it  was  limited  in  approach  range  because 
of  the  mechanics  of  the  system.  With  the 
early  models,  you  could  not  go  much  closer 
than  one  mile  to  the  shore  or  object  of 
interest  whether  it  be  at  the  pier,  sin¬ 
gle  point  mooring,  or  whatever. 

Even  with  all  of  their  limitations, 
these  simulators  in  Holland  were  an  excit¬ 
ing  and  successful  breakthrough.  Immedi¬ 
ately  demand  for  training  time  on  them  was 
high.  A  number  of  important  decisions 
regarding  training  of  officers  to  handle 
the  new  and  imposing  VLCC ' s  were  made  us¬ 
ing  these  devices.  As  a  result,  VLCC 
masters  were  now  required  to  spend  time  on 
a  simulator  before  they  were  given  the  new 
command.  In  this  way,  it  was  possible  for 
them  to  experience  the  vessel's  handling 
characteristics  and  gain  a  feel  for  its 
dynamics  in  advance  of  the  ship's  trial 
runs . 

But  this  was  only  the  beginning  with 
respect  to  simulation.  Plans  were  already 
being  made  for  simulators  in  other  count¬ 
ries.  For  instance,  the  Computer  Aided 
Operations  Research  Facility  (CAORF)  was 
conceptualized  about  this  time.  Another 
entry  in  the  field;  Marine  Safety  Inter¬ 
national,  envisioned  a  simulator  design 
approach  that  would  give  them  a  marketable 
tool  for  training  of  deck  officers.  In 
Japan,  work  on  electronic  ship  simulation 
of  one  form  or  another  had  been  underway 
for  some  time  by  I.H.I.  and  Mitsubishi  and 
within  some  of  the  maritime  schools. 

Dr.  Kensaku  Nomoto  of  the  Osaka  Uni¬ 
versity,  Department  of  Naval  Architecture, 
designed  a  simulator  built  by  the  students 
that  was  a  hybrid  configuration.  By  using 
computer-controlled  special  effects  such 
as;  sea  scape,  clouds,  sky,  generated  by 
an  analogue  such  as  a  transparency  rotat¬ 
ing  on  a  motor  controlled  base,  he  was 
able  to  produce  a  color  enriched  back¬ 
ground.  The  other  contacts  (sometimes 
called  target  ships)  were  a  series  of 
models  that  were  placed  on  a  turntable 
that  could  be  controlled  in  rotation.  A 
zoom  lens  equipped  video  vamera  projected 
the  model's  image  through  a  color  TV  three 
gun  system  on  to  the  screen.  The  simula¬ 


tor,  driven  by  an  old  Hitachi  analogue 
computer,  performed  well  even  though  it 
was  a  very  simple  bridge  configuration 
with  equipment  consisting  of  the  helm, 
engine  order  telegraph,  RPM,  Rudder  Angle 
Indicator  and  radio  communications. 

Meanwhile,  ship  simulator  activity 
was  underway  in  the  U.K.  These  develop¬ 
ments  concentrated  on  a  pure  nocturnal 
scene  using  spot  projectors  to  display 
ship,  shore  and  navigation  lights.  The 
Decca  Company  with  Pat  Hansford’s  "sealing 
wax  and  string"  model  of  a  nocturnal 
simulator  showed  much  promise.  While  the 
limited  field  of  view  of  110°  left  much 
to  be  desired,  the  reasonable  cost  of 
the  device  made  it  attractive.  The 
National  Maritime  Institute,  the  source 
of  funds  and  direction  for  the  project, 
eventually  developed  five  of  these  devices. 


Each  had  a  very  tidy  bridge,  small 
but  configured  to  have  all  the  essentials 
of  any  well  ordered  ships  bridge.  The 
early  models  had  a  flying  spot  scanner 
radar  simulator  that  later  was  replaced 
by  a  digital  landmass  system.  It  can  be 
said  that  this  simulator  was  a  useful 
tool . 

3.  Current  Technology 

With  each  new  requirement  for  ship 
simulation,  higher  demands  were  made  on 
the  fidelity  of  the  simulation  itself.  A 
wider  field  of  view,  two  points  abaft 
abeam,  more  realism  in  the  scene,  more 
flexibility,  better  math  models  of  own 
ship,  all  of  these  requirements  were  laid 
on  as  a  result  of  a  perceived  need.  Al¬ 
most  all  of  these  new  devices  were  intend¬ 
ed  for  training.  Therefore  the  bridge 
layouts,  the  instructor  controls  and  the 
visual  systems  were  designed  to  support  a 
training  mission  only. 

However,  in  the  United  States,  the 
Computer  Operations  Research  Facility 
(CAORF)  was  hog  inning  to  come  on  line. 

Its  mission,  different  than  one  of  strict¬ 
ly  training,  was  to  determine  some  of  the 
long  required  answers  *o  the  problem  of 
marit'me  personnel  and  the  handling  of 
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Projection  of  the  nocturnal  scit.o  in- 
accomplished  utilizing  a  series  of  compu- 
tor-control-led  pro  lectors.  Each  project¬ 
or  is  capable  of  projecting  a  spot  of 
light  which  can  be  varied  in  position, 
intensity  and  color  (white,  rod,  green  or 
yellow).  In  the  present  configuration, 
either  simulator  is  capable  of  generating 
a  total  of  fifteen  ships  in  a  full  360° 
night  scene.  This  capability  can  he 
expanded . 

Each  year  many  ships  are  damaged  or 
lost  due  to  heavy  weather.  The  simple 
expedient  of  reducing  speed  and  reorient¬ 
ing  the  ship's  course  with  regard  to  wave 
motion  is  well  known.  A  master's  range 
of  experience  necessary  to  make  maneuver¬ 
ing  decisions  in  heavy  weather  may  be 
limited.  Yet,  if  he  is  forced  to  maneuver 
such  as  in  collision  avoidance  or  at  an 
imperative  junction  point,  he  must  rely 
on  this  experience  and  whatever  visual 
input  is  available.  A  great  deal  of 
thought  and  discussion  went  into  the  need 
for  motion  to  provide  realistic  simulation 
of  all  relevant  aspects  of  handling  a 
ship  in  heavy  weather.  These  include  the 
external  influences  acting  on  the  ship 
motion  in  both  longitudinal  and  lateral 
direction,  in  yaw,  roll  and  pitch;  the 
effects  of  wind  and  current  varying  in 
speed  and  direction  with  time;  the  effect 
of  waves  varying  in  direction,  time  and 
size.  It  was  necessary  to  consider  water 
depth  and  effects  of  landmass.  However, 
no  studies  or  operations  research  on 
motion  in  marine  simulation  had  boon  done 
which  could  act  as  a  guide.  Thus,  the 
inclusion  of  a  6°  motion  base  was  strict¬ 
ly  a  practical  decision  recognizing  that 
costs  to  retrofit  at  a  later  date  would 
be  extremely  expensive. 

In  motion  simulation,  the  human 
threshold  of  response  to  acceleration 
measures  from  .003  to  .045  m/secp 
About  ten  times  this  value  and  more  can 
be  obtained  in  the  wheelhouse  for  the 
simulation  of  roll  and  pitch  motions  of  a 
small  ship  (30,000  DWT)  in  a  heavy  sea. 
Even  the  small  values  of  acceleration  due 
to  heave  can  be  sensed.  The  system 
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Considerable  interest  has  Urt  .  ’  .ire 
in  the  industry  by  our  decision  to  ;  re¬ 
cced  with  a  motion  base  on  t  he  simulator. 

It  is  felt  that  much  can  be  learned 
concerning  heavy  weather  shinhandl in-:  an! 
the  effects  of  prolonged  exposure  to 
motion  using  this  controlled  environment. 

At  present.,  the  constraint  to  improv¬ 
ing  simulator  fidelity  is  the  inability  to 
protect  a  higher  quality  scene.  This 
means  the  apparatus  between  the  scene  data 
store,  be  it  film  or  computer,  is  incapa¬ 
ble  of  reproducing  even  a  small  degree  of 
the  quality  available  from  this  store. 
Considering  computer-gonerated  image  (CGI ), 
it  can  be  argued  that  high  resolution  is 
within  the  state-of-the-art  as  far  as  the 
computer  is  concerned.  Therefore,  the 
quality  breakdown  must  be  beyond  that 
point  or  between  the  projector  device  and 
the  resolving  surface  or  the  screen. 

Many  innovative  approaches  have  been 
evaluated,  but  in  the  end,  all  of  the 
computer-generated  systems  end  up  using  a 
series  of  video  rasters  end  on  end  to 
achieve  a  wide-angle  field  of  view.  As 
each  "swatch"  subtends  approximately  44° 
horizontally,  it  is  necessary  to  have 
eight  or  nine  video  projecting  elemeits  to 
achieve  a  360°  field  of  view.  Much  of  the 
problem  of  poor  fidelity  stems  from  the 
matching  of  these  rasters  and  from  the 
use  of  the  NTSC  525-line  standard.  The 
use  of  commercially  available  three-gun 
projectors  does  not  enhance  the  situation. 
Usually  low  cost,  they  are  also  low  output. 
Although  there  has  been  an  attempt  to  use 
a  film  base  system  for  daylight  projection 
it  has  been  less  than  a  tremendous  success; 
and  therefore  can  be  classed  alona  with 
the  other  approaches  in  use  at  the  present 
time,  which  can  bo  described  as  useful  but 
not  tlic  ultimate  answer. 

What  then  is  the  answer  to  the  mari¬ 
time  wide-angle  field  of  view  roqui rement? 
Where  are  we  going,  and  when?  In  1983, 
the  first  glimmer  of  a  breakthrouqh  came 
when  the  laser  was  finally  used  in  a  video 
projection  system  by  Dwight  Cavendish  of 
the  u.E. 

His  system  is  the  first  that  promises 
a  commercially  successful  laser  device  for 
"O'oo  project  i  on  .  "in  device  could  be 
the  basis  of  the  next  major  step  in  a 
seamless,  wide-angle  video  picture. 

The  system  consists  of  a  blue-white  ion 
laser  beam  that  is  split  into  its  bluo- 
green-red  components  through  optical 
prisms.  Each  of  these  separated  beams  is 
directed  through  crystal  lattice  modula¬ 
tors  that  are  energizes!  from  the  ECU  d r i "e 
of  the  video  stream. 


ships  at  sea.  Now  with  the  auvont  of 
CAORF,  the  long  costly  process  of  design¬ 
ing  vessels  could  easily  include  the 
important  man-machine  interface.  This 
meant  it  was  possible  to  evaluate  control 
functions  and  predict  their  effect.  In 
other  words,  simulation  now  gave  the  de¬ 
signer  and  the  researcher  a  means  bv  which 
data  that  had  previously  had  to  wait  tie 
trial  test,  could  now  be  assembled  and 
verified  safely  and  accurately. 
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M.I.T.A.G.S.  is  the  largest  simulator 
based  maritime  training  facility  in  the 
world  today.  The  range  of  these  training 
devices  includes  a  tanker  loading  simula¬ 
tor,  cryogenic  cargo  simulator,  steam 
turbine  simulator,  a  radar  simulator  that 
includes  eight  own  ships,  an  electronic 
navigation  trainer/simulator,  and  two 
total  environment  ship  simulators.  These 
ship  simulators  provide  a  360°  field  of 
view.  The  bridge  is  designed  to  allow 
complete  flexibility  in  equipment  layout. 
The  size  is  thirty-six  feel  by  twenty- 
four  feet  ( 36 1 x24 1 )  and  will  allow  the 
training  of  a  complete  bridge  team. 
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The  heart  of  any  ship  simulator  for 
training  purposes  lies  in  the  ability  to 
convey  to  the  trainee  the  visual  realism 
either  in  a  night  or  day  environment. 

This  aspect  of  simulator  capability  must 
be  carefully  considered  based  on  the  tech¬ 
niques  available.  At  MITAGS,  our  reso¬ 
lution  requirement  of  one  minute  of  arc 
precluded  the  use  of  current  state-of-the- 
art  visual  techniques.  This  requirement 
was  based  upon  the  premise  that  the 
primary  input  device  for  the  watch  officer 
was  his  eye,  and  a  watch  officer's  natural 
response  to  an  initial  sighting  or  radar 
contact  is  to  attempt  further  identifica¬ 
tion  of  the  contact  with  binoculars.  Of 
course,  this  is  not  possible  with  current 
computer-generated  imagery  (CGI)  or  video/ 
model  board  systems  (VMB)  and  therefore, 
computer-controlled  synthesized  (CCSI) 
imagery  was  selected.  In  CCSI  scene 
generation,  the  image  is  projected  onto  a 
hyperspher ical  screen  located  fifty  feet 
from  the  optical  center  of  projection. 

This  distance  is  beyond  the  ability  of  the 
eye  to  range  by  separation  and  restricts 
ranging  to  object  association. 

Because  statistics  presently  show 
that  over  seventy  percent  of  the  casualties 
that  result  from  a  breakdown  of  judgmental 
skills  occur  at  night,  we  have  restricted 
ourselves  to  a  pure  nocturnal  scene.  A- 
nother  factor  which  weighed  heavily  in 
favor  of  delaying  acquiring  a  daylight- 
visual  capability  was  the  poor  quality  of 
the  projected  scene  using  the  current 
techniques.  Limited  light  level  and  the 
need  to  match  together  several  rasters  for 
a  wide  ancle  field  of  view  lid  not  satisfy 
our  needs.  We  have  a  project  underway  at 
this  time  that  will  provide  a  Uv  contin¬ 
uous  seamless  picture.  This  work  is  base  i 
on  recently  developed  laser  techniques, 
which  will  be  covered  in  the  following 
paragraphs . 
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The  output  of  these  modulators  is  again 
reunited  into  a  coherent  beam  which 
produces  the  horizontal  scan  through  the 
action  of  a  rotating  polygon  mirror.  The 
points  or  facets  of  the  polygon  are  as  it 
rotates,  the  start  and  the  end  of  each 
sweep.  Another  mirror  device  driven  at 
the  frame  rate  frequency  produces  the 
vertical  deflection  of  the  beam.  These 
two  devices  are  locked  together  through  a 
comparator  to  the  sync  signal  of  the 
video  stream. 

At  M.I.T.A.G.S.  work  is  being  done 
on  a  modification  of  this  type  of  system 
to  allow  for  a  360°  projection  system. 

This  envisions  vertical  scanning  as  oppos¬ 
ed  to  horizontal  scanning  at  a  frame  rate 
of  60  cycles.  However,  the  aspect  would 
change  from  the  3  x  4  of  the  ordinary 
raster  to  a  30°  included  angle  vertically 
by  360°  horizontally.  The  Cavendish  ro¬ 
tating  polygon  mirror  system  would  be 
maintained,  but  it  would  now  displace  the 
laser  beam  in  the  vertical.  The  oscillat¬ 
ing  mirror  for  providing  the  vertical 
framing  would  be  eliminated,  and  a  rotat¬ 
ing  projection  head  would  take  its  place. 
For  a  two  minute  of  arc  separation 
between  the  vertical  scan  lines,  it  would 
be  necessary  to  rotate  the  head  at  3600 
rpm  and  have  a  scan  rate  of  10,500  cycles 
per  second.  While  these  numbers  are 
imposing  for  mechanical  devices,  it's  not 
an  impossibility,  and  the  work  done  to 
date,  has  shown  promise. 

In  the  past,  much  effort  has  been 
expended  trying  to  establish  the  minimum 
visual  input  that  would  be  considered 
useful  for  a  day  or  night  ship  simulator. 
While  this  effort  may  have  been  useful, 
it  is  certain  that  when  a  modestly  priced 
yet  effective  computer-controlled  wide- 
angle  visual  scene  is  available,  it  will 
be  warmly  welcomed  by  all. 
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ABSTRACT 


The  U.S.  Navy  has  undertaken  a  shiphandling  trainer  design  and  development  project  for 
the  purpose  of  upgrading  existing  training.  Naval  officers  at  all  career  levels  have  had 
fewer  opportunities  to  acquire  and  practice  shiphandling  skills  because  of  a  considerable 
reduction  in  underway  steaming  time.  A  functional  design  has  been  generated  that  describes 
several  design  alternatives  ranging  from  expensive,  full  mission,  high  fidelity,  bridge 
simulators  to  smaller  part -task  devices  that  train  principles  and  concepts.  The  Navy  has 
determined  that  a  relatively  small,  less  expensive  part -task  trainer  may  meet  most  of  the 
requirements  for  training  basic  and  intermediate  level  shiphandling  skills  in  the  areas  of 
shiphandling:  alongside,  in  restricted  waters,  in  open  ocean,  during  mooring  and  anchoring, 
and  for  tactical  operations.  A  model  device  has  been  developed  that  allows  the  Navy  an 
opportunity  to  evaluate  each  of  the  proposed  trainer  subsystems  under  consideration  for 
final  engineering  design.  Major  subsystems  include  a  computer  generated  imagery  (CGI) 
visual  display,  computer  aided  instruction  (CAI),  and  a  situation  display  that  affords 
immediate  and  delayed  performance  feedback  during  and  after  training  exercises.  Future 
research  using  this  model  will  provide  important  information  concerning  subsystem  training 
effectiveness  and  the  fidelity  requirements  for  major  areas  of  shiphandling  training. 


INTRODUCTION 

Conning  officers,  who  are  responsible  for 
the  safe  maneuvering  of  ships  require  a  special¬ 
ized  set  of  cognitive  skills.  Traditionally 
junior  officers  have  been  provided  both  the  time 
and  opportunity  to  develop  these  skills  on-the- 
job  while  underway.  Unfortunately,  as  the 
Navy's  high  technology  operational  systems  have 
increased  in  complexity,  the  training  responsi¬ 
bilities  of  commanding  officers  has  taxed  sche¬ 
dules  and  facilities  to  their  limit.  More  of 
what  a  naval  officer  does  at  sea  has  been 
devoted  to  tactical  and  engineering  requirements 
leaving  a  limited  amount  of  time  for  training 
and  practice  of  the  skills  of  shiphandling.  In 
addition,  continuing  high  fuel  costs  and  short¬ 
ages  have  reduced  total  underway  time,  which  had 
been  used  for  practice  and  training  of  ship¬ 
handling  skills. 

To  maximize  training  effectiveness  for  the 
time  and  resources  that  are  available,  the  Navy 
has  initiated  a  program  to  provide  quality  ship¬ 
handling  training  for  all  officers  who  require 
it.  This  paper  briefly  describes  the  program 
and  then  explores  in  some  detail  a  research  pro¬ 
ject  aimed  at  developing  one  component  of  the 
shiphandling  training  system  -  a  part-task 
device. 

Training  Problem 

Several  years  ago  the  Naval  Training  Equip¬ 
ment  Center  (NAVTRAEQUIPCEN)  began  to  closely 
examine  the  training  requirements  of  Navy  ship- 
handlers  to  determine  ways  for  enhancing  the 
quality  and  increasing  the  opportunities  for 
shiphandling  training  (Hanley,  Bertsche,  and 
Hammell,  1982). L'J  As  a  first  step,  a  problem 
analysis  was  undertaken  that  resulted  in  a  ship¬ 
handling  job  and  task  analysis  of  the  Surface 
Warfare  Officer  (SWO).  Supporting  skills  and 


knowledge  elements  were  derived  which  were  com¬ 
pared  to  those  addressed  in  existing  Navy  ship¬ 
handling  training  programs.  Current  programs 
were  compared  to  the  training  demand  for 
officers  serving  in  seagoing  commands  who  were 
expected  to  handle  the  ship  as  part  of  their 
job.  An  estimate  of  the  total  training  demand 
was  made  to  understand  the  magnitude  of  training 
need  and  the  qualitatively  different  types  of 
training  necessary  to  address  most  shiphandling 
training  requirements. 

Training  demand  was  estimated  by  surveys  of 
the  major  school  and  operational  SWO  commands. 
In  addition  to  the  total  number  of  Surface  War¬ 
fare  Officer  billets  (approximately  12,000), 
several  other  factors  were  examined  to  help 
identify  existing  training  requirements  includ¬ 
ing: 

Types  of  Training  Required.  The  numbers  of 
officers  within  basic.  Intermediate,  and 
advanced  skill  levels  were  estimated.  These 
skill  groupings  are  consistent  with  career 
development  paths  described  in  NAVPERS  15197A 
("Unrestricted  Line  Officer  Career  Guidebook"). 
Numbers  were  derived  from  counting  the  number  of 
active  Navy  ships  in  service  and  estimating  the 
number  of  officers  who  regularly  conn  a  ship. 
This  method  provided  conservative  estimates  of 
training  requirements. 

Ouring  1981  it  was  estimated  that  approxi¬ 
mately  750  basic,  1250  intermediate,  and  767 
advanced  officers  would  be  available  for  train¬ 
ing  based  on  a  50  percent  availability  of 
officers  assigned  to  seagoing  commands.  These 
large  numbers  of  trainees  would  require  initial 
training  and  periodic  refresher  training. 

Training  Opportunities.  A  survey  was  made 
of  Navy  officers  for  time  spent  at  sea  under 
instruction  and  actually  conning  a  ship.  Addi- 
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tionally,  training  opportunities  at  shore  faci¬ 
lities  were  surveyed.  It  was  clear  from  the 
analysis  that  additional  training  sites  and 
media  must  be  developed  to  supplement  existing 
Navy  training  efforts.  In  either  area,  oppor¬ 
tunities  for  training  were  found  to  be  extremely 
limited.  Existing  training  facilities  ashore 
were  few,  and  equipment  limited  in  its  avail¬ 
ability  to  school  and  operational  commands. 
At-sea  opportunities  for  training  have  been 
reduced  because  of  a  fleet  wide  reduction  in 
steaming  time. 

Location.  The  dispersion  of  fleet  units 
across  major  U.S.  ports  on  either  coast  requires 
the  distribution  of  training  capabilities  in 
many  locations  rather  than  several  central 
ones.  The  Surface  Warfare  Officer  Schools  in 
Newport,  Rhode  Island,  and  San  Oiego,  Cali¬ 
fornia;  the  Fleet  Training  Centers  in  Norfolk, 
Virginia,  and  San  Oiego,  California;  the  Naval 
Academy,  Reserve  Centers  and  a  number  of  major 
naval  bases  are  all  potential  offerers  of  ini¬ 
tial  and  refresher  shiphandling  training. 

Shiphandlinq  Training  System 

As  a  result  of  the  training  analysis,  and 
subsequent  media  selection  process,  a  ship¬ 
handling  training  system  has  been  derived.  The 
media  chosen  for  delivering  training  ranged  from 
simple  audio-visual  aids  to  a  very  complex,  full 
bridge  simulator  which  incorporates  a  220-degree 
horizontal  field  of  view  visual  scene.  A  number 
of  similar  shiphandling  simulators  are  in  exis¬ 
tence  today.  The  level  of  visual  fidelity  which 
they  provide  is  necessary  for  the  training  and 
practice  nf  intermediate  and  advanced  ship- 
handlers.  The  cost  to  the  Navy  for  these  simu- 
|  lators,  however,  may  prohibit  their  acquisi- 

i  tion.  In  addition,  there  is  some  question  as  to 

whether  basic  shiphandling  trainees  can  benefit 
fully  from  a  high  fidelity  simulator  with  a 
limited  number  of  instructional  features. 

To  fill  the  gap  which  exists  between  audio/ 
visual  media  and  full  bridge  simulators,  the 
NAVTRAEQUIPCEN  has  recommended  that  a  relatively 
low-cost,  part-task  device  be  developed  which 
will  be  used  to  teach  basic  shiphandlers  the 
concepts  and  principles  necessary  to  gain  ship¬ 
handling  cognitive  skills.  The  part-task  ship¬ 
handling  device  which  is  described  in  detail 
below,  is  the  first  of  its  kind  to  incorporate 
visual  imagery,  computer-assisted  instruction 
and  a  plan  position  indicator  in  the  same 
device.  In  order  to  determine  the  efficacy  of 
this  type  of  approach  and  also  to  examine  some 
of  the  research  issu.s  which  must  be  answered,  a 
preprototype  model  of  the  part-task  device  is 
being  developed  by  the  Human  Factors  Research 
Laboratory  of  NAVTRAEQUIPCEN. 

PART-TASK  SHIPHANOLING  TRAINING  OEVICE  MODEL 

The  model  (Figure  1)  called  PARTT-SHIP  will 
be  used  as  a  research  tool  to  establish  the 
degree  of  training  effectiveness  resulting  from 
its  current  design.  The  goal  of  the  PARTT-SHIP 
program  is  to  demonstrate  the  training  effec¬ 
tiveness  of  a  low  cost  shiphandling  training 
capability  which  can  be  distributed  to  training 
locations  where  need  is  demonstrated.  As  a 
research  tool,  the  PARTT-SHIP  design  is  flexible 


and  reconfiguration  is  possible  to  examine  the 
unique  contributions  of  its  major  subsystems  to 
the  total  training  effect.  Each  subsystem  is 
explained  in  the  following  paragraphs. 

Computer  Generated  Imagery  (CGI) 

A  computer  generated  imaging  subsystem  is 
provided  that  displays  a  150-degree  (75  degrees 
either  side  relative  to  ownship's  forward  longi¬ 
tudinal  axis)  horizontal  field  of  view  (Figure 

2) .  The  vertical  field  of  view  is  22.5  degrees, 
5.6  degrees  up  and  16.9  degrees  down.  The  scene 
is  full  color  including  ownship's  bow  and  vari¬ 
ous  day  and  nighttime  images. 

Plan  Position  Indicator  (PPI) 

A  "birds  eye"  view  CRT  display  of  an  exer¬ 
cise  area  is  provided  during  exercises  (Figure 

3) .  Ownship  is  at  the  center  of  the  screen. 
Land  edges,  piers,  channel  edge,  etc.,  are  shown 
in  solid  and  dashed  line  format.  The  display  is 
capable  of  supporting  instruction  in  docking, 
anchoring,  tug  handling,  and  restricted  waters 
navigation  through  a  series  of  specialized  dis¬ 
play  enhancements.  A  series  of  vector  functions 
representing  ownship's  predicted,  actual,  and 
historic  movements  aid  instruction  in  the  con¬ 
cepts  and  principles  of  shiphandling. 

Computer  Aided  Instruction  (CAI) 

Giving  the  student  a  means  for  individually 
operating  the  model  device  will  allow  the 
instructor  to  focus  on  the  quality  of  instruc¬ 
tion  and  the  needs  of  the  student.  Automation 
of  this  sequence  reduces  instructor  burdens  for 
mechanically  controlling  training.  A  dedicated 
CAI  plasma  display  introduces  the  student  to 
exercise  objectives;  gives  tutorial  by  way  of 
"help"  functions  prior  to  exercise  run,  scores 
performance  and  displays  feedback  to  the  stu¬ 
dent.  Subject  areas  are  under  the  direction  of 
the  instructor  and  he  controls  every  portion  of 
the  training  sequence  from  an  instructor  con¬ 
sole,  should  he  desire. 

Training  scenarios  have  been  designed  to 
simulate  the  real  world  demands  of  maneuvering  a 
single  screwed  Navy  combatant  (FFG-7)  in  a 
channel  although  any  ship  can  be  modelled. 
Variable  wind  and  current  effects  are  simulated 
in  an  ecologically  valid  manner  to  increase  the 
difficulty  of  training  scenarios  according  to 
the  stage  of  training  and  skill  level  of  a 
student . 

PARTT-SHIP  Functional  Description 

The  PARTT-SHIP  model  is  enclosed  in  a 
training  carrel  with  approximate  dimensions  of 
10  feet  wide,  6  feet  high,  and  6  feet  deep.  It 
accommodates  three  students  comfortably  at  the 
control  panels.  Students  alternate  as  conning 
officer,  auxiliary  control  panel  operator,  and 
helm  operator.  Auxiliary  panel  and  helm  opera¬ 
tors  are  seated  while  the  student  acting  as 
conning  officer  is  free  to  move  about  the 
carrel.  In  addition  to  the  trainer,  the  carrel 
contains  a  small  chart  table  and  a  chart  storage 
facility.  Trainees  not  conning  the  ship  operate 
the  trainer  under  the  direction  of  the  student 
acting  as  conning  officer.  In  its  current  con- 
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figuration  the  instructor  manually  controls  a 
fixed  sequence  of  assigned  instructional  steps 
that  are  dependent  upon  the  students  achieving  a 
preset  criterion  level  of  performance.  Practice 
exercises  are  selected  by  the  instructor  and 
each  simulator  exercise  scenario  is  initialized 
automatically.  The  trainee  may  run,  freeze,  or 
terminate  the  exercise  scenario.  Performance 
measures  are  automatically  recorded  by  the 
PARTT-SH1P  device  and  can  be  displayed  as 
instructional  feedback  following  exercise 
scenarios.  In  a  production  mode,  it  is  antici¬ 
pated  that  many  of  the  functions  currently  per¬ 
formed  by  the  instructor  could  be  automated. 

The  device  provides  a  real  time,  dynamic 
simulation  of  a  selected  ownship  and  exercise 
area.  Generic  stylized  ship  controls  are  pro¬ 
vided  which  allow  the  trainee  to  control  the 
ship's  rudder,  engine,  propeller  pitch,  auxilia¬ 
ry  propulsion  units,  anchors,  and  servicing  tug¬ 
boats.  The  status  of  these  controls  and  ship 
performance  parameters  are  displayed  on  generic 
indicators.  The  principal  display  for  the 
trainee  is  computer  generated  imagery  in  the 
five-CRT  configuration  that  comprises  a  150- 
degree  horizontal  field  of  view.  This  is  coor¬ 
dinated  with  an  enhanced  plan  position  indicator 
(PPI)  representation  of  the  geographic  area  that 
provides  a  "birds-eye"  view  of  the  exercise  and 
ownship's  position.  The  situation  display  also 
presents  the  future  course  of  the  ship  based  on 
external  sources  acting  on  the  ownship  and  an 
estimated  prediction  of  the  ship  maneuvering 
response  to  various  trial  rudder  and  engine  com¬ 
mands.  The  visual  system  uses  computer  gene¬ 
rated  Imagery  (CGI)  technology  that  generates 
Images  of  simple  aids  to  navigation,  docking 
structures,  and  ownships  bow  for  day  condi¬ 


tions.  Night  conditions  consist  of  lights  on 
traffic  ships,  and  cultural  objects/land  for 
night  conditions.  The  training  device  may  be 
operated  with  either  or  both  the  situation  dis¬ 
play  and  visual  display  systems. 

The  FFG-7  model  includes  auxiliary  propul¬ 
sion  unit  characteristics,  autopilot,  passing 
ship  interactions,  anchor  effects,  tug  effects, 
wind,  and  current  effects.  Figure  2  is  a  sim¬ 
plified  system  diagram  of  the  PARTT-SHIP  hard¬ 
ware  configuration  that  has  been  developed  for 
the  demonstration  model.  Major  subsystems  are: 

•  CAI  controls  and  display  systems 

•  Ship  control  and  indicator  subsystem 

•  Situation  display  subsystem 

•  Visual  display  subsystem 

The  model  is  driven  by  a  host  computer 
multiprocessor  that  controls  the  functions  of 
image  processing  units,  radar  graphics  proces¬ 
sors,  and  a  multichannel  interface  unit. 


Situation  Display.  The  situation  display 
is  provided  to  allow  the  student  an  enhanced 
navigation  and  maneuvering  display  in  place  of  a 
traditional  radar.  The  PARTT-SHIP  model  is  not 
a  radar  trainer.  The  PPI  display  is  a  situation 
presentation  format  that  was  chosen  over  a  tra¬ 
ditional  radar  display  because  of  its  increased 
training  capability  through  special  instruc¬ 
tional  features. 

The  display  includes  distinct  symbols  for 
anchors,  tugboats,  piers,  and  other  navigational 
aids.  Channel  boundaries  show  areas  and  motion 
vectors  that  can  be  displayed  on  the  PPI  to  aid 
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Figure  4.  PARTT-SHIP  Bridge  Control  Panel 
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the  student  in  negotiating  various  restricted 
waters  situations.  A  special  set  of  vector 
functions  are  included  as  part  of  the  PPI  capa¬ 
bility  that  will  display  past  ownship  track  in¬ 
formation,  a  predictor  steering  feature,  and  a 
scenario  freeze  capability.  The  trainee  may 
choose  to  examine  his  historical  performance  or 
up  to  3  minutes  of  the  ships  predicted  future 
course.  These  functions  are  carried  in  fast 
time  while  the  scenario  is  in  run  or  is  frozen. 
Traditional  radar  features  ( i . e . ,  range  and 
bearing)  can  also  be  displayed.  Using  a  PPI 
representation,  the  student  is  less  apt  to 
attempt  mastery  of  radar  operations  since  opera¬ 
tion  of  the  PPI  situation  display  is  simplis¬ 
tic.  Operating  device  controls  demand  little 
attention  from  the  trainees  to  increase  the 
probability  that  the  student  attends  to  the 
principles  and  concepts  of  shiphandling  rather 
than  the  mechanical  operation  of  the  trainer. 


feature  cues  the  trainee  so  that  he  may  Direct 
his  attention  to  important  features  within  the 
exercise.  It  is  also  a  means  by  which  the 
instructor  can  judge  how  well  the  trainee  is 
absorbing  the  instructional  materials. 

Before  exercise  run,  a  PARTT-SHIP  “help" 
feature  can  be  called  upon  for  a  brief  tutorial 
of  principles  and  concepts  related  to  the 
scenario.  The  trainee  need  only  touch  the 
appropriate  area  on  the  plasma  "help"  display 
for  a  number  of  various  menus  to  appear  within 
which  the  student  can  select  (Figure  5). 
Several  levels  of  branching  have  been  designed 
so  that  the  student  can  access  the  level  of 
instruction  required  for  his  particular  entry 
level  skills  and  knowledge.  The  tutorial  struc¬ 
ture  is  flexible  yet  easy  to  follow. 

TRAINING  EFFECTIVENESS  EVALUATION 


Bridge  Controls.  The  generic  bridge  design 
includes  a  number  of  stylized  controls  and  indi¬ 
cators  that  were  included  to  reduce  the  amount 
of  familiarization  time  necessary  within  the 
trainer  before  training  can  begin  (Figure  4). 
The  controls  are  simple  pushbuttons  which  simu¬ 
late  the  function  of  real  world  bridge  equip¬ 
ment.  The  stylized  generic  nature  of  the  con¬ 
trols  and  indicators  make  the  training  device 
applicable  across  a  wide  variety  of  ship  classes 
and  ship  types  without  sacrificing  face  valid¬ 
ity.  The  goal  of  the  design  was  to  make  the 
operation  of  the  trainer  straightforward  and 
simplistic.  This  minimizes  the  necessary  task 
demands  for  operating  the  device  so  that 
students  can  pay  attention  to  the  important 
information  being  displayed  in  the  visual  scene, 
situation  display,  and  computer  aided  instruc¬ 
tional  display. 

Gaming  Area.  The  nature  of  computer 
generated  imagery  (CGI)  systems  is  such  that 
reprogramming  of  new  gaming  areas  or  switching 
from  one  gaming  area  to  another  can  be  done 
rapidly  and  inexpensively.  Any  number  of  major 
U.S.  Navy  ports  or  other  ports  of  interest  may 
be  called  upon  for  instructional  purposes 
limited  only  by  computer  storage  capacity  and 
data  base  availability.  Special  features  of 
each  gaming  area  are  accurately  programmable 
since  the  environmental  equations  that  model 
each  data  base  are  sophisticated.  The  effects 
of  bank,  cushion,  shallow  water,  passing  ship, 
current,  wind,  bottom  composition,  and  a  number 
of  other  environmental  parameters  are  designed 
into  the  hydrodynamic  equations  that  control  the 
portrayed  motion  of  ownship  through  the  gaming 
area. 
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CAI  Functions.  A  computer  aided  instruc¬ 
tional  capabi 1 lty  has  been  designed  for  use 
before,  during,  and  after  exercise  run.  No 
shiphandling  trainer  presently  uses  a  CAI 
feature,  so  its  effectiveness  will  be  closely 
monitored  in  this  project.  These  functions  are 
used  to:  explain  the  operation  of  the  trainer, 
exercise  objectives,  and  performance  feedback 
information  to  the  student.  Additionally,  CAI 
functions  have  the  capability  of  interrupting  a 
training  scenario  to  question  the  trainee  con¬ 
cerning  various  exercise  scenario  features  with 
which  the  student  should  be  familiar  or  should 
be  anticipating  during  the  exercise  run.  This 


-•>  -■ . 


Design  of  the  PARTT -SHI P  model  was  a 
product  of  front-end  analysis  that  included  user 
inputs  and  expert  analyses  in  the  areas  of 
training,  operation,  and  engineering.  Many 
design  steps  were  taken  to  maximize  potential 
training  benefits  to  Navy  shiphandlers.  How¬ 
ever,  as  in  any  development  the  validity  of 
design  must  be  examined  through  actual  use.  To 
avoid  the  incorporation  of  unneeded  model 
features  into  the  final  engineering  design,  a 
series  of  model  evaluations  have  been  con¬ 
ducted.*  Goals  of  the  evaluations  are  to 
experimentally  test  the  training  effectiveness 
of  the  PARTT-SHIP  design  and  to  collect  expert 
shiphandler  evaluations  of  training  potential 
for  the  existing  model.  Information  gained  from 
evaluations  will  be  used  to  improve  the  final 
engineering  design  specification. 

Two  questions  have  been  posed  concerning 
the  PARTT-SHIP  model: 

1.  Can  basic  and  intermediate  level  ship- 
handlers  receive  comparable  training  with  the 
part -task  trainer  as  with  a  full-scale  ship¬ 
handling  simulator? 

2.  What  features  of  PARTT-SHIP  are  neces¬ 
sary  for  good  training,  i.e.,  CGI,  PPI,  and  CAI? 

A  training  effectiveness  evaluation  (TEE)  has 
been  conducted  to  answer  these  questions  and  is 
described  below. 

Comparative  Evaluations 

Two  experiments  were  planned  to  investigate 
the  measurable  training  gains  of  the  model. 
Each  was  designed  as  a  before  and  after  study  to 
compare  entry  level  shiphandling  skills  of 
junior  Navy  officers  to  skill  levels  demon¬ 
strated  after  training.  Figure  6  is  a  diagram¬ 
matic  representation  of  planned  treatments  and 
control  groupings.  The  simplified  block  dia¬ 
grams  and  drawings  below  each  capability  repre¬ 
sent  the  configurations  that  will  be  compared. 
An  example  of  one  treatment  is  the  "PARTT-SHIP 

♦Note:  At  the  time  of  this  writing,  the  evalua¬ 
tions  were  just  beginning.  Preliminary  results 
of  the  study  will  be  distributed.  In  addition, 
final  results  may  be  obtained  by  writing  to  the 
authors. 
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EXPERIMENTAL  DESIGN 
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Figure  6.  TEE  Experimental  Design 


without  (wo)  CGI"  (PARTT-SHIP  without  computer 
generated  imagery)  shown  for  Experiment  1.  It 
can  be  seen  that  the  CGI  display  screens  are  not 
included  in  that  drawing. 

Experiment  1  investigated  the  training 
effectiveness  of  the  PARTT-SHIP  model  for 
restricted  waters  shiphandling.  Subjects  in 
this  experiment  were  junior  Surface  Warfare 
Officer  students  from  Surface  Warfare  Officer 
School  (Basic). 

The  principal  comparison  was  between  train¬ 
ing  conducted  on  a  full-mission  bridge  simulator 
and  that  conducted  on  the  PARTT-SHIP  model. 
Entry  skill  levels  of  students  trained  on  either 
device  were  balanced  along  with  scenario  dif¬ 
ficulty,  scenario  length,  training  objectives, 
instructors,  and  total  time  of  training.  This 
allows  a  direct  comparison  of  final  posttraining 
skills  and  training  gains  between  training 
devices.  Comparisons  were  also  made  between 
pretest  and  posttest  performances  within  control 
and  treatment  groups  to  examine  the  total  train¬ 
ing  gain. 

Three  other  comparisons  were  planned  to 
test  the  effectiveness  of  reduced  PARTT-SHIP 
configurations.  Reduced  designs  were  accom¬ 
plished  by  removing  the  CGI,  CAI,  and  PPI  sub¬ 
systems  one  at  a  time  and  to  test  their  indivi¬ 
dual  effects.  A  separate  group  of  trainees  was 
instructed  with  each  reduced  version  of  the 
trainer.  Each  treatment  (PARTT-SHIP)  group  was 
compared  to  one  another  and  to  a  control  group 
trained  on  a  full-mission  simulator. 

Experiment  2  was  a  separate  but  similar 
experiment  run  with  other  groups  of  trainees 
within  the  area  of  collision  avoidance  but 
without  the  reduced  trainer  comparisons. 


Qualitative  Evaluation 

Each  experimental  subject  and  all  Navy 
personnel  taking  part  in  demonstrations  of  the 
model  have  filled  out  a  device  rating  question¬ 
naire.  It  was  designed  to  record  and  quantify 
opinions  of  the  model's  training  potential. 

Research  Hypotheses** 

Expected  findings  from  experimental  efforts 
can  be  summarized  in  several  specific  hypotheses. 

Hypothesis  1.  Principal  comparisons  be- 
tween  treatment  and  control  groups  will  show  no 
difference.  This  would  mean  that  the  PAkTT-SHIP 
model  approaches  or  equals  full  scope  bridge 
simulation  training  capabilities  within  the 
areas  tested.  This  outcome  was  expected  because 
of  the  similarity  of  functional  capabilities  in 
each  device.  Primary  physical  differences  exist 
for  the  size  of  the  bridge  area  and  the  fidelity 
of  the  bridge  controls  and  control  panels. 
Visual  scenes  are  essentially  the  same.  Train¬ 
ing  displays  were  the  primary  functonal  differ¬ 
ence. 

Hypothesis  2.  When  comparing  "reduced" 
versions  of  the  PARTT-SHIP  model  to  one  another 
and  to  training  on  a  full-mission  simulator, 
removal  of  any  one  subsystem  (i.e.,  CGI,  CAI,  or 
PPI  displays)  was  expected  to  affect  the  speed 
of  learning  and  therefore  the  total  training 
effect.  No  a  priori  rankings  of  the  training 
effectiveness  of  any  one  subsystem  was  predicted. 


‘♦Whether  these  hypotheses  have  been  supported 
or  refuted  will  be  discussed  in  the  additional 
pages  distributed  at  the  conference. 
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Hypothesis  3.  Although  performance  gain 
was  expected  to  be  equal  between  control  and 
treatment  groups  within  either  training  area, 
subjects  trained  on  the  PARTT-SHIP  mcdel  may 
have  experienced  a  performance  decrement  during 
simulator  posttest.  This  could  have  occurred 
since  a  degrading  in  performance  between  part- 
and  full-task  trainers  was  ^ound  by  Williams, 
Goldberg,  and  D'Amico,  1980,”]  in  a  simulator 
study  of  Chief  Mates  shiphandling  behaviors. 
Although  training  gains  were  equivalent  for 
students  training  on  a  full-scope  (full-task) 
simulator  and  a  reduced  bridge  (similar  to  the 
PARTT-SHIP  model).  Chief  Mates  having  trained  on 
the  reduced  bridge  experienced  significant 
deficiencies  in  performance  when  transitioning 
to  the  higher  fidelity  full  scope  simulator  for 
more  training  and  testing.  Although  those  sub¬ 
jects  differed  somewhat  from  the  Navy  population 
(i.e.,  junior  Navy  officers),  it  is  reasonable 
to  assume  that  such  a  deficit  may  occur  in  the 
PARTT-SHIP  experiments  during  posttest. 

Hypothesis  1  is  not  contradictory  to 
Hypothesis  3  although  the  former  predicted  no 
difference  between  treatment  and  control  groups 
while  the  latter  predicted  a  possible  differ¬ 
ence.  Hypothesis  1  was  concerned  with  training 
effectiveness  with  respect  to  device  types  as 
measured  by  pretest/posttest  comparisons. 
Hypothesis  3  predicted  that  subjects  from  treat¬ 
ment  conditions,  who  were  trained  on  the  PARTT- 
SHIP  device,  may  have  experienced  performance 
decrements  on  a  full  bridge  simulator  posttest 
following  training.  Hypothesis  1  was,  there¬ 
fore,  a  comparison  of  training  gain  within 
devices  as  measured  on  each  device  while  Hypoth¬ 
esis  3  was  concerned  with  measures  of  training 
effectiveness  as  measured  by  the  simulator 
alone.  These  predictions  wer^  not  mutually 
exclusive. 

CONCLUSIONS 

High  accident  rates  over  the  last  few  years 
prompted  the  Chief  of  Naval  Operations  in  1979 
to  make  the  area  of  shiphandling  training  a  high 
priority  objective  for  improvement.  The  ship¬ 


handling  training  program  under  development  at 
NAVTRAEQUIPCEN  will  go  a  long  way  towards  meet¬ 
ing  that  objective.  Special  emphasis  is  being 
given  to  the  numerous  research  questions  which 
must  be  answered  concerning  the  part -task  device 
preprototype,  especially  since  it  is  the  first 
of  its  kind.  Will  it  be  training  effective? 
Which  elements  of  the  device  are  most  impor¬ 
tant?  What  will  be  the  opinion  of  experienced 
shiphandlers  about  the  efficacy  of  the  device? 
The  results  from  the  current  study  will  hope¬ 

fully  provide  the  answers  necessary  to  make  the 
part-task  approach  an  effective  and  efficient 
element  of  the  total  shiphandling  training 
system. 
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ABSTRACT 

Non-real-time  feasibility  was  demonstrated  in  1982  for  a  hybrid 
visual/sensor  simulation  approach  which  merges  two  technologies.  Computer 
Generated  Imagery  (CGI)  and  Computer  Synthesized  Imagery  (CSI)  to  form 
Computer  Generated  Synthesized  Imagery  (CGSI).  This  approach  holds  promise  as 
a  cost-effective,  attainable  method  of  providing  real-time,  high  detail 
imagery  for  visual  and/or  other  sensors,  such  as  FLIR.  Because  of  the  high 
potential  payoff  from  the  development  of  this  hybrid  approach,  a  current 
program  is  aimed  at  demonstrating  feasibility  of  this  CGSI  technology  in  real¬ 
time.  CGSI  uses  a  modular  set  of  building  blocks  which  may  be  configured  to 
meet  specific  training  and  simulation  requirements.  The  pipeline  processor  is 
the  major  element  in  a  CGSI  system.  The  pipelines  accept  control  commands 
from  the  Field  of  View  (FOV) /Controller  module  and  input  video  data  containing 
objects  from  the  data  base.  The  Pipeline  Processor  then  outputs  transformed 
objects  to  the  scene-construction  module  and  special-effects  module.  To 
control  risks,  a  single  pipeline  is  being  fabricated  and  tested  before  the 
remaining  modules  and  additional  pipelines  are  fabricated.  The  feasibility 
demonstration  of  a  single  pipeline  is  scheduled  for  September  1983.  The 
results  of  these  tests  will  be  included  in  the  oral  presentation  at  the 
conference,  but  unfortunately  will  not  be  available  in  time  to  meet  the  publi¬ 
cation  deadline  for  the  written  paper.  A  description  of  the  test  procedure  is 
included  here. 


INTRODUCTION  ated  Imagery  Systems  lack  scene  content  to 

support  this  type  of  training. 

Requirements 

This  paper  addresses  a  new  technique 
Sophistication  of  weapons  systems  is  being  developed  to  increase  visual  and 

growing  at  a  rapid  pace.  This  sophistica-  sensor  simulation  system  fidelity  and 

tion  takes  many  forms  including  increased  capability.  Honeywell's  Systems  and 
operational  capability  through  use  of  Research  Center  is  presently  under  con- 

multiple  sensor  systems  including  FLIR  tract  to  the  Naval  Training  Equipment 

(Forward  Looking  Infrared),  Imaging  RADAR,  Center  and  the  Army  Project  Manager  for 

LLLTV  (Low  Light  Level  TV)  in  combination  Training  Devices  to  develop  this  increase 

with  out-the-window  visual.  Proper  task  in  visual  system  capability  and  fidelity, 

loading  is  often  necessary  to  train  opera-  The  system  under  development  will  merge 

tors  and  maintain  skills  in  the  use  of  the  attributes  of  an  optical  disc  technol- 

sophisticated  weapon  systems.  The  argu-  ogy  approach.  Computer  Synthesized  Imagery 

ments  against  using  operational  assets  (CSI)  ,  and  Computer  Generated  Imagery 

include  cost  and  safety.  There  is,  (CGI).  CSI  provides  high  quality  imagery, 
therefore,  a  need  for  increased  fidelity  but  does  not  provide  free  movement  within 

through  simulation.  Current  approaches  in  a  gaming  area.  CGI  provides  the  necessary 

visual  and  sensor  simulation  are  inade-  freedom  of  movement,  but  with  highly 

quate  for  tactical  training.  Modelboard  stylized  or  cartoonish  imagery.  This 

systems  lack  the  ability  to  provide  multi-  hybrid  concept  of  Computer  Generated  Syn- 

spectral  imagery,  weapons  effects,  moving  thesized  Imagery  (CGSI)  utilizes  optical 

targets,  large  gaming  areas,  and  wide  disc  photographic  imagery  (CSI)  oveilayed 

fields  of  view.  Present  Computer  Gener-  onto  a  CGI  background.  In  addition  to 
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displaying  individual  objects  in  a  scene.  The  U.S.  Army  requirements  are  for  the 

the  system  is  capable  of  displaying  groups  AH-64  Apache  helicopter  combat  mission 

of  objects,  imagery  as  seen  from  various  simulator.  Visual  requirements  encompass 

sensors  (e.g.,  FLIR  and  LLLTV)  and  adding  weapons  effects  and  delivery,  wide  field 

smoke  and  other  special  effects.  Initial  of  view  displays  to  support  nap-of-the- 

non-real-time  feasibility  of  this  hybrid  earth  flight,  multiple  viewpoints,  multi¬ 
system  has  been  demonstrated  (1).  Addi-  pie  sensors  and  multiple  magnifications 

tional  work  is  necessary  and  is  being  through  a  telescoping  systems.  The  Apache 

pursued  to  provide  a  real-time  capability  requirements  are  felt  to  be  one  of  the 

(i.e.,  a  minimum  update  field  rate  of  60  most  demanding  in  the  simulation  industry 

Hz).  Detailed  design  of  a  limited  system  today.  The  system  described  here  could 

was  completed  in  April  1983  (2).  CGSI  provide  a  capability  to  meet  these  re¬ 
uses  a  modular  set  of  building  blocks  quirements.  The  CGSI  system  has  potential 

which  may  be  configured  to  meet  specific  application  for  providing  air-to-ground 

training  and  simulation  requirements.  The  capability  in  the  U.S.  Navy's  F/A-18 

pipeline  processor  is  the  major  element  in  Hornet  fighter/attack  aircraft  simulators 

a  CGSI  system.  The  pipeline  processors  and  for  filling  low  level  contour  training 

change  a  stored  image  to  scene  conditions  requirements  on  the  CH-53  D/E  and  CH-46 

(screen  coordinates)  by  changing  image  helicopter  simulators.  One  of  the  extreme- 

position,  size,  rotation,  warp,  and  inten-  ly  attractive  features  of  this  approach  is 

sity.  The  Pipeline  Processors  then  output  the  potential  for  utilizing  CGSI  to  retro- 

transformed  objects  to  the  scene-construc-  fit  existing  CGI  systems  to  increase  per- 

tion  module,  pixel  by  pixel,  based  upon  formance.  The  Air  Force's  interest  in 

range.  The  pipelines  will  operate  as  this  development  results  from  the  need  for 

single,  large  object  processors;  as  multi-  high  fidelity  simulation  for  air-to-ground 

pie,  small  object  processors;  or  as  attack  missions.  The  Air  Force  Human 

special  effects  processors.  Resource  Laboratory  ( AFHRL )  has  provided 

funding  support  for  the  CGSI  feasibility 
A  top-level  system  specification  for  demonstration, 
each  subsystem  has  been  prepared.  These 

specifications  contained  two  key  elements  CGSI  System  Overview 
-  performance  and  I/O  requirements.  After 

the  specifications  were  reviewed  and  The  single  pipeline  is  an  integral 

approved  by  both  the  Government  and  part  of  the  entire  CGSI  system.  Therefore, 

Honeywell,  the  detailed  design  effort  a  brief  functional  overview  of  a  real-time 

began.  Each  subsystem  was  designed  as  a  CGSI  system  will  be  given  here  in  order  to 

unit,  with  individualized  hardware  and  provide  understanding  of  the  single  pipe- 

software.  This  detailed  design  of  the  line  in  its  proper  context.  Figure  1  is  a 

pipeline  has  been  completed.  The  pipeline  functional  overview  of  a  real-time  CGSI 

processor  subsystem  is  the  most  complex  system.  The  functional  blocks  are  separ- 

subsystem.  Therefore,  to  control  risks,  a  ated  into  an  off-line  non-real-time  data 

single  channel  is  being  fabricated  and  base  construction  module  and  a  real-time 

tested  before  the  remaining  modules  and  processing  system.  A  brief  description  of 

additional  pipelines  are  fabricated.  The  each  module  follows, 

feasibility  demonstration  of  a  single 

pipeline  was  performed  in  early  September  The  data  base  consists  of  two  very 

1983.  different  types  of  data  -  the  object 

library  and  the  gaming  area.  The  object 
The  CGSI  system  has  been  selected  for  library  contains  images  of  objects  and 

a  competitive  fly-off  to  provide  next  surfaces  in  different  spectral  bands,  and 

generation  visual  and  sensor  simulation  transmissivity  masks  of  special  effects, 

technology  development  for  the  U.S.  Army.  The  gaming  area  data  base  provides  the 

Technology  being  developed  under  this  Army  information  necessary  for  placing  the 

contract  builds  on  a  feasibility  demon-  contents  of  the  object  library  in  the 

stration  contract  received  from  gaming  area.  The  objects  in  the  library 

NAVTRAEQUIPCEN.  This  joint  Navy/Atmy/Air  may  be  either  stationary  or  capable  of 

Force  effort  will  first  demonstrate  the  movement.  The  vehicle  simulation  computa- 

real-time  feasibility  of  the  CGSI  concept.  tions  determine  the  locations  and  viewing 


Figure  1.  CGSI  Functional  Overview 


direction  of  the  visual  or  sensor  systi r 
for  the  primary  vehicle.  The  FOV  proces¬ 
sor  determines  the  presence  of  objects,, 
surfaces,  and  special  effects  in  the  scene 
under  construction.  The  output  of  a 
transformation  matrix  converts  the  real- 
world  coordinates  to  screen  coordinates. 
The  controllers  fan  out  and  process  the 
control  functions  generated  during  the  FOV 
computation.  The  processed  control  func¬ 
tions  are  passed  to  the  object/surface/ 
special  effects  processing  channels.  The 
object,  surface,  special  effects  (OSSE) 
library  stores  the  images  used  to  con¬ 
struct  a  scene.  The  controllers  command 
the  selected  images  which  are  passed  to 
the  processing  channels.  The  individual 
processing  channel  pipelines  process  one 
object,  surface  or  special  effect  per 
channel.  All  the  processing  channels 
operate  in  an  identical  manner.  The 
object,  surface,  special  effect  channels 
change  a  stored  image  (normal  perspective) 
to  scene  conditions  (screen  coordinates) 
by  changing  image,  position,  size,  rota¬ 
tion  and  warp.  Image  intensity  is  modi¬ 
fied  based  upon  range  and  object  type. 
The  scene  construction  module  takes  the 
individual  image  from  each  processing 
channel,  separates  the  image  from  the 
background,  and  assembles  the  scene  based 
upon  range.  The  high  frequency  edges 
generated  by  assembling  a  scene  from  indi¬ 
vidual  images  are  smoothed,  matching  edge 
and  internal  frequencies.  The  translucent 
special  effects  are  added  after  the  gener¬ 
ation  of  the  scene.  The  special  effects 
module  adds  the  special  effects  based  upon 
range.  Special  effects,  such  as  smoke  or 
dust,  may  occur  ahead  of  or  behind  images 
in  the  scene.  The  intensity  masks  are 
stored  in  the  object  library  and  processed 
in  the  special  effects  processing  channel. 


In  this  section,  the  functional  over¬ 
view,  shown  in  Figure  1,  is  expanded  to 
provide  a  generic  hardware  overview  for  a 
single  pipeline  and  scene  construction  and 
special  effect  components  (Figure  2) .  The 
system  is  modular;  a  small  system  may 
contain  only  several  OSSE  processors  and  a 
large  system  may  contain  several  hundred 
OSSE  processors.  It  is  the  intent  of  this 
design  to  allow  the  system  to  produce  any 
type  of  imagery,  visual,  IR,  MMW  (Milli¬ 
meter  Waves) ,  SAR  (Synthetic  Aperture 
Radar),  radar,  etc.  Current  funding  in¬ 
cludes  simulation  of  visual  and  IR 
imagery. 

Each  object,  stored  group  of  objects, 
surface  or  special  effect  is  individually 
processed  by  an  OSSE  processor  and  used  to 
construct  a  scene  in  the  scene  construc¬ 
tion  module  and  special  effects  module. 
Depending  on  the  size  of  an  OSSE  image, 
the  OSSE  processors  handle  from  1  to  16 
OSSEs  per  channel.  In  this  section  the 
path  of  an  image  (one  full  image  or  up  to 
16  small  images)  will  be  traced  from  the 
image  storage  media  to  the  image  display 
subsystem.  The  processing  of  the  image 
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Figure  2.  CGSI  Configuration  Elements 

during  its  flow  through  the  pipeline  is 
under  the  control  of  a  Field  of  View 
(FOV)  controller.  All  OSSEs  are  processed 
in  the  same  manner  at  the  beginning.  De¬ 
pending  on  the  function,  major  changes 
occur  in  the  scene  construction  modules 
and  special  effects  modules.  Nontrans- 
lucent  objects  and  surfaces  (trees,  rocks, 
bushes,  tanks,  etc.)  are  combined  in  the 
scene  construction  module.  Realistic  color 
or  true  color  can  be  applied.  Realistic 
color  is  generated  via  lookup  tables  and 
uses  one  pipeline,  while  true  color  uses 
three  pipelines,  one  each  for  red,  green 
and  blue. 

A/D  Conversion.  A  high  speed  A/D 
module  converts  the  analog  video  imagery 
to  digital  data.  The  module  operates  near 
8  MHz  and  provides  8-bit,  or  256  gray 
shade,  output. 

Frame  Buffer.  The  frame  buffer  is 
controlled  by  the  OSSE  controller;  it  is 
used  to  store  images  that  are  not  chang¬ 
ing.  This  includes  distant  2D  objects  and 
all  surfaces  and  special  effects.  The 
warping  process  may  compress  data  result¬ 
ing  in  loss  of  resolution  in  the  trans¬ 
mitted  imagery  if  the  image  is  rotated 
beyond  50  or  60  degrees.  To  limit  rota¬ 
tions  to  +  45  degrees,  a  high  speed  memory 
design  is  used  which  can  be  accessed  in 
both  the  X  and  Y  axis.  As  a  result,  one 
image  may  be  rotated  a  full  360  degrees 
without  degradation  through  line  and 
column  memory  access. 

Frame  Buffer  Switch.  The  frame  buffer 
switch  allows  the  imagery  to  be  held  in 
the  frame  buffer  for  repeated  use  of  2D 
objects,  surfaces  and  special  effects. 
After  an  OSSE  is  stored  in  the  frame  buff¬ 
er,  the  optical  disc  may  be  used  to  apply 
imagery  to  other  channels.  For  dynamic  3D 
objects,  the  frame  buffer  allows  the 
imagery  to  be  taken  directly  from  the 
optical  disc  without  any  delays.  The 
frame  buffer  switch  is  controlled  by  the 
OSSE  control le r . 
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Intensity  Modifier.  The  intensity 
modifier  modifies  the  intensity  of  a  scene 
in  both  global  and  local  manners.  Global 
changes  use  a  LUT.  As  an  example,  these 
changes  may  be  associated  with  range;  that 
is,  an  object  at  a  distance  is  more  satur¬ 
ated  and  bluer  than  the  same  object  at  a 
very  short  range.  Local  modifiers  multi¬ 
ply,  on  a  real-time  basis,  each  image 
pixel  by  an  LUT  value.  The  LUTs  contents 
are  a  function  of  position  within  the 
frame.  The  intensity  modifier  introduces 
only  pixel  delays. 

I  Axis  Processing.  The  algorithm  for 
distorting  an  object  operates  in  two 
passes.  Before  explaining  the  Y  axis 
functions,  an  overview  of  the  warping 
function  is  presented.  The  warping  algo¬ 
rithm  contained  in  the  pipeline  operates 
in  two  passes;  first  the  Y  axis  and  then 
the  X  axis.  The  field  microprocessor 
determines  the  offset  (starting  location), 
the  magnification  (change  in  line  length) 
of  the  first  line  in  each  axis  and  selects 
the  field  memory  buffers.  The  line  micro¬ 
processor  determines  the  delta  offset  and 
delta  magnification  of  each  line.  The 
field  microprocessor  operates  in  a  16 
millisecond  cycle  and  the  line 
microprocesot  in  a  63  microsecond  cycle. 
The  pixel  processors  operate  on  the  pixel 
streams  in  a  100  nanosecond  cycle  or  10 
MHz.  During  the  first  pass  of  the  Y  axis, 
each  line  in  the  row  may  be  distorted  in 
one  or  more  of  the  following  manners: 
Linear,  perspective,  curved,  lens  correc¬ 
tion  or  multi-object  (2) . 


The  three  field 
buffer  allows  the  Y  axis  processed  image 
to  be  read  into  two  field  buffers,  one  for 
odd  pixels  and  one  for  even  pixels.  The 
third  field  buffer  allows  either  odd  or 
even  fields  to  be  processed  in  the  X  axis 
processor . 


The  techniques 
used  in  the  X  axis  could  be  identical  to 
those  used  in  the  Y  axis  which  includes 
the  following  functions:  Linear,  Perspec¬ 
tive,  Curved,  Lens  Correction,  and  Multi- 
Objects.  In  addition,  for  potential 
applications  where  perspective  distortions 
in  the  real-world  are  not  identical  in  the 
X  and  Y  axis,  the  X  axis  processing  could 
use  algorithms  which  differ  from  the  algo¬ 
rithms  used  in  the  Y  axis.  This  case 
could  occur  with  dome  projection  display 
systems  or  Synthetic  Aperture  Radar  (SAR) 
imaging  systems. 


If  the  system  requires  other  than  525  line 
video,  a  line  rate  converter  changes  the 
line  rate  of  525  lines  to,  for  example, 
875  or  1024  lines  by  changing  the  pixel 
clock  rate.  The  line  rate  converter  does 
not  add  lines  or  pixels;  it  only  changes 
the  rate  at  which  the  pixels  are  clocked 
in  and  out.  In  converting  a  525  line 
syster  to  1024  line,  for  example,  only  1/4 
of  the  1024  system  is  covered  by  a  single 
525  line  input.  The  line  rate  converter 


is  a  f i r st- in/f i r st-out  buffer  (FIFO)  that 
synchronized  and  positions  the  525  line, 
10  MHz  imagery  to  and  within  the  1024 
line,  40  MHz  imagery. 

Realistic _ Qoloz .  The  CGSI  approach 

has  been  developed  to  provide  monochrome; 
realistic  color;  or  full,  true -color  capa¬ 
bility  (See  Figure  3).  True  color  is 
provided  through  the  creation  of  three 
spectrally  distinct  data  bases  -  each 
full-color  photograph  is  digitized  and 
stored  separately  using  optical  quality 
red,  green  and  blue  filters.  When  a  full 
color  image  is  displayed,  the  red,  green 
and  blue  object  images  are  independently 
processed  and  delivered  to  the  red,  green 
and  blue  channels  of  the  color  display 
system  used.  One  can  see  that  full  color 
is  bought  for  a  price:  three  times  as 
many  processing  channels  are  required 
relative  to  the  number  needed  to  generate 
a  monochromatic  version  (e.g.,  IR)  of  the 
same  object  image.  Near-perfect  color  is 
achievable  in  a  much  more  economical  man¬ 
ner.  Most  OSSEs  contain  only  shades  of 
one  or  two  colors;  i.e.,  consider  green 
leaves,  brown  branches,  blue  water,  camou¬ 
flaged  targets.  Look-up  table  manipula¬ 
tion  techniques  permit  the  generation  of 
realistic  (as  opposed  to  true)  object  and 
surface  color  on  the  basis  of  mapped  gray- 
shade  imagery.  The  realistic  color 
approach  allows  the  CGSI  system  to  gener¬ 
ate  terrain,  vegetation  and  object  colors 
with  one-third  the  processing  required. 
To  obtain  realistic  color,  each  object  is 
stored  as  a  spectrally  mapped  image. 
Associated  with  each  image  is  a  red,  green 
and  blue  LUT  conversion  that  assigns  up  to 
256  colors  to  gray  shade  levels  of  the 
image.  The  256  colors  that  are  achievable 
may  be  256  shades  of  one  hue  -  for 
example,  shades  of  green  to  create  a  high 
fidelity  color  image  of  a  bush  -  or  256 
distinct  hues.  The  process  is  thus  pre¬ 
cisely  controllable,  and  provides  adequate 
color  capability  for  combat  mission  train¬ 
ing  simulations. 

SINGLE  PIPELINE  TEST  PROCEDURE 

A  single  CGSI  pipeline  design  has 
been  completed  as  described  above.  The 
feasibility  demonstration  is  scheduled  for 
September  1983.  A  test  plan  has  been 
developed  to  verify  the  operation  of  this 
single  pipeline  and  will  be  described 
here.  The  objectives  of  this  demonstra¬ 
tion  are  to  verify  the  speed  and  accuracy 
of  a  single  pipeline,  to  provide  contrac¬ 
tor  in-plant  testing  of  a  single-pipeline, 
and  to  provide  real-time  warping  of  2D 
objects  and  3D  objects  for  both  the  visual 
and  IR  spectral  regions.  Figure  4  gives  a 
system  block  diagram  for  the  single  pipe¬ 
line  feasibility  demonstration. 

Measurements  of  speed  will  include 
both  throughput  lag  and  update  rate. 
Figure  5  gives  the  nominal  design  timing 
for  the  CGSI  systems.  Throughput  lag 
(transport  time)  is  defined  as  the  time 
between  the  receipt  of  positional  informa- 
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Figure  3.  Color  Hardware  Configuration 
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Figure  4.  Single  Pipeline  Feasibility 
Demonstration 


Figure  5.  CGSI  System  Timing 

tion  from  the  vehicle  simulation  computer 
to  the  comple  tion  of  the  picture  scan. 
Based  on  use  of  a  specific  test  pattern, 
the  delay  from  receipt  of  positional 
change  information  at  the  FOV  computer  to 
a  change  in  output  pixel  value  will  be 
measured  with  a  logic  analyzer.  Update 
rate  is  defined  as  the  rate  at  which 
vehicular  position  may  be  changed.  The 

design  target  upaate  rate  is  60  Hz.  The 
operator  will  start  the  simu  lation, 
causing  the  object  to  be  displayed  and 
move.  Motion  will  occur  because  the  FOV 
simulator  outputs  coordinates  to  the 

"pipeline"  via  the  IEEE  488  interface  at  a 
60  Hz  rate.  Delta  values  will  be  applied 
at  each  update  by  the  simulation  program 
to  make  the  object  move  on  the  screen. 
Proper  rate  of  motion  will  be  verified  by 
having  the  image  processor  sample  frames 
out  of  the  pipeline.  These  frames  will 
then  be  analyzed  off-line  to  verify  that 
the  pixel (s)  are  in  the  expected  loca¬ 
tion^)  for  the  particular  frame  sample 
times . 


Measurements  of  accuracy  will  include 
both  measurements  of  screen  location  and 
timing.  Screen  location  is  defined  as  the 
absolute  location  of  the  object  within  the 
FOV  as  expected  from  commands  transmitted 
to  pipeline  by  the  FOV  computer.  The  test 
object  will  be  translated  in  x,y,  magni¬ 
fied,  compressed,  and  rotated  independent¬ 
ly  and  in  combination.  The  output  of  the 
pipeline  is  fed  back  into  the  image  pro¬ 
cessor  (See  Figure  4).  The  image  proces¬ 
sor  will  enable  non-realtime  simulated 
imagery  to  be  compared  to  real  time 
pipeline  imagery  such  that  the  monitor 
will  display  the  object  in  three  colors  as 
follows:  R=pipeline  modified  object, 
G=image  processor  modified  object,  B=back- 
ground.  The  image  processor  and  trackball 
will  be  used  in  combination  to  find 
differences  between  these  images.  Differ¬ 
ences  will  also  show  up  obviously  as 
yellow  on  the  color  monitor.  All  differ¬ 
ences  shall  involve  1  pixel  or  less.  The 
timing  of  an  object  relative  to  the  hori¬ 
zontal  sync  signal  shall  be  controlled  to 
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ensure  object  to  object  alignment  at  the 
scene  construction  module.  The  operator 
shall  select  an  object  which  consists  of  a 
single  pixel  located  in  a  known  time  slot 
on  a  known  line.  An  oscilloscope  shall  be 
used  on  the  pipeline  output  video  to 
measure  the  location  of  the  single  output 
pixel  relative  to  the  line  sync  and  the 
master  sync. 

The  image  stability  will  be  tested. 
Image  stability  is  defined  as  the  constant 
location  of  an  object  from  frame  to  frame 
in  time.  The  operator  will  select  an 
object  to  be  sent  through  the  pipeline. 
The  image  processor  will  be  used  to 
periodically  sample  a  group  of  three 
frames.  The  image  processor  will  be  used 
off-line  from  the  test  with  the  pipeline 
to  measure  the  location  of  the  pixel 
matrix  in  each  sample  frame.  The  matrix 
location  shall  vary  by  no  more  than  +/-1 
pixel  from  the  average  (nominal)  location 
across  all  of  the  sample  frames.  In  add¬ 
ition  to  the  above  quantative  tests,  the 
following  qualitative  demonstrations  will 
be  observed.  The  image  quality  shall  be 
photographic  quality  with  minimum  degrada¬ 
tion  resulting  from  processing.  The  cap¬ 
ability  of  warping/displaying  2D  and  3D 
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objects  for  both  visual  and  IR  will  be 
observed.  The  capability  to  interface  the 
pipeline  to  a  video  disc  player  will  be 
demonstrated.  Realistic  motion  of  objects 
will  be  assessed. 

SOURCE  OF  DIGITIZED  IMAGERY 
FOR  A  SINGLE  PIPELINE 

A  point  which  may  seem  obvious  to 
some,  but  is  worthy  of  emphasis,  is  that  a 
single  pipeline  can  process  any  type  of 
digitized  data.  It  is  immaterial  what 
region  of  the  spectrum  (visual,  IR,  RADAR, 
MMW)  is  represented  by  the  imagery  or  what 
the  original  source  of  the  imagery  was 
(real-world  object,  physical  model  of 
object,  non-real-time  CGI). 

Current  funding  provides  for  simula¬ 
tion  of  visual  and  FLIR  using  the  CGSI 
pipelines.  Qualitative  analysis  indicates 
that  other  imaging  sensors  such  as  SAR  and 
MMW  could  also  be  handled  by  CGSI 
pipel ines . 

Figure  6  emphasizes  the  fact  that  the 
source  of  the  digitized  imagery  is  var¬ 
iable.  The  CGSI  pipeline  can  warp  and 
properly  inset  any  digitized  image  into  a 
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scene.  Figure  6  is  a  CGSI  synthesized 
composite  scene  which  illustrates  three 
alternatives.  It  shows  a  real  helicopter 
image  which  has  been  properly  inserted 
into  the  mid-ground  of  a  forest  scene. 
It  is  obvious  that  in  the  real-world,  it 
will  not  always  be  possible  to  photograph 
target  objects  at  close  range  from  various 
aspect  angles.  One  alternative  is  illus¬ 
trated  in  the  foreground.  A  model  tank  has 
been  constructed,  photographed,  digitized 
and  properly  inserted  into  this  same 
scene.  In  addition,  computers  are  capable 
of  generating  highly  detailed,  realistic 
objects  in  non-real-time.  This  non-real- 
time  CGI  (computer  generated  imagery) 
could  provide  input  to  the  CGSI  pipelines 
as  illustrated  in  the  sky.  The  fixed  wing 
aircraft  is  a  non-real-time  CGI  image.  In 
some  cases,  non-real-time  CGI  may  provide 
a  viable  alternative  for  feeding  a  CGSI 
pipeline . 

The  critical  point  to  emphasize  here 
is  that  the  single  CGSI  pipeline  has  been 
designed  to  be  a  highly  flexible,  modular 
building  block  for  providing  high  fidelity 
visual  and  sensor  simulation  to  meet  a 
wide  range  of  training  simulation 
requirements . 

MULTIPLE  PIPELINE  CONFIGURATIONS 

As  the  CGSI  concept  moves  into  physi¬ 
cal  realization  in  a  real-time  demonstra¬ 
tion,  its  application  to  real-time  train¬ 
ing  visual  and  sensor  systems  become  prac¬ 
tical  and  advantageous.  Such  application 


is  clearly  warranted  whenevei  high  object 
fidelity  or  high  data  base  flexibility  is 
required,  although  other  instances  of 
favorable  application  exist. 

This  CGSI  development  is  unique  for  a 
research  effort.  Critical  considerations 
are  being  designed  into  the  system  from, 
the  ground  up.  These  include  reliability, 
maintainability,  integrated  logistics 
support  as  well  as  development,  produc¬ 
tion,  and  support  cost  issues.  CGSI  is 
being  designed  as  a  system  that  works  and 
will  continue  to  work  in  a  cost  effective 
manner  in  an  actual  training  environment. 
This  is  an  extremely  ambitious  under¬ 
taking.  However,  if  these  critical  con¬ 
siderations  are  not  designed  into  the 
system  initially,  extensive  redesign  would 
be  necessary  in  order  to  provide  a  capa¬ 
bility  for  answering  real  training  prob¬ 
lems  in  the  field. 

System  Analysis.  Based  upon  the 
identified  training  mission  requirements, 
CGSI  systems  configuration  development 
becomes  an  iterative  sequence  of  refine- 
ments/trade-off s  involving  the  various 
CGSI  building  blocks  previously  described. 
The  elements  to  be  considered  in  addition 
to  the  training  mission  requirements  are 
considerations  of  reliability,  maintain¬ 
ability,  integrated  logistics  support  as 
well  as  development,  production  and 
support  cost  issues.  Table  1  gives  a 
listing  of  CGSI  system  building  blocks  and 
the  configuration  rules  for  developing  a 
large  CGSI  system. 


Table  1.  Configuring  a  CGSI  System  from  Building  Blocks 


0 

SELECT  DATA  SOURCE 

1) 

VIDEO  DISK 

2) 

WRITE-ONCE  VIDEO  DISK 

3) 

MAGNETIC  STORAGE 

4) 

GRAPHICS 

o 

SELECT  PROCESSOR 

1) 

OSSE 

2) 

OSEE/W/TRUE  PERSPECTIVE 

3) 

GRAPHICS 

4) 

CGI 

o 

MAKE  525  OR  HIGHER  RESOLUTION 

1) 

10  MHZ,  OR 

DECISION. 

2) 

40  MHZ  FOLLOW-ON  CARDS  (ADD 
LINE  RATE  CONVERTER) 

0 

MAKE  B/W,  TRUE  VS  REALISTIC 

COLOR  DECISION 

(ADD 

COLOR  LOCK-UP  TABLE  (LUT)) 

0 

IS  ITERATIVE  SCENE  DEVELOPMENT 

(ADD 

ITERATIVE  RANGE  AND  IMAGE 

REQUIRED? 

MEMORIES) 

0 

IS  CHANNEL  IR,  VISUAL  B/W,  OR 
VISUAL  COLOR? 

1) 

IR  SMOOTHING,  VISUAL  SMOOTHING 

0 

SELECT  NUMBER  OF  SPECIAL 

EFFECTS  CHANNELS. 

0 

CONFIGURE  TIMING  CONTROL, 
FIRMWARE,  AND  SOFTWARE  TO 

MATCH. 
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every  new  application  will  require  unique 
responses. 


These  trade-offs  take  two  forms:  1) 
balancing  training  effectiveness  versus 
cost,  and  2)  trading  off  technically 
limiting  parameters  to  achieve  optimum 
system  performance.  The  training  effec¬ 
tiveness  trades  are  primarily  related  to 
number  of  OSSE  channels  required.  When 
the  training  mission  analysis  has  defined 
the  characteristics  and  count  of  the  ob¬ 
jects  to  be  presented,  an  obvious  but 
simplistic  approach  to  configuration  would 
be  to  provide  a  channel  per  object.  This, 
however,  would  produce  an  excessively 
large  and  costly  system  when  alternatives 
exist  with  either  no  or  minimal  training 
impact.  The  number  of  OSSE  channels  re¬ 
quired  can  be  traded  off  against:  1)  Off¬ 
line  development  of  composite  scene  views 
(clusters),  2)  On-line  iterative  composite 
scene  construction,  3)  Area  of  Interest 
(AO I )  displays,  multiple  resolution  dis¬ 
plays,  4)  Realistic  versus  true  color. 
(True  color  channels  can  be  mixed  with 
realistic  channels  if  required  for  selec¬ 
ted  critical  objects) ,  5)  Training  Cue 
Fidelity  (This  trade  area  is  the  most 
subjective  but  provides  the  most  opportun¬ 
ity  for  ingenuity  of  approach),  6)  Avail¬ 
ability  (For  very  large  visual  systems, 
system  reliability  becomes  a  training 
issue  because  of  significant  failure  rates 
and/or  extended  repair  times).  Numerous 
alternative  implementations  and  trades 
exist  beyond  these  six  in  configuring  a 
CGSI  system.  Trade  alternatives  exist  in 
the  purely  technical  realm  also.  An  ex¬ 
ample  is  transport  delay/update  time. 
While  the  nominal  transport  delay  of  an 
OSSE  process  is  related  to  a  512  X  512 
image  area,  smaller  image  definition  (say 
256  X  256)  will  yield  shorter  trans¬ 
port  delays  by  reducing  the  field  process¬ 
ing  time. 

As  an  example,  a  CGSI  configuration 
for  a  small  visual  system  could  provide 
potential  applications  for  periscope 
training  or  hand-held  missile  or  gunnery 
applications.  Figure  7  shows  a  non-real¬ 
time  CGSI  scene  of  a  view  thru  a  periscope 
which  could  be  provided  in  real-time  by  a 
small  CGSI  configuration.  Figure  8  de¬ 
picts  a  CGSI  configuration  capable  of 
providing  this  image.  Figure  9  shows  a 
non-real-time  CGSI  scene  of  a  AH-64  flying 
among  the  trees  which  could  be  provided  in 
real-time  by  a  large,  robust  CGSI  config¬ 
uration.  Figure  10  depicts  a  CGSI  con¬ 
figuration  capable  of  providing  this 
imagery  level  with  all  sensors  supported 
for  team  training. 

Design .  The  system  analysis  trades 
result  in  specific  design  requirements 
related  to  configuration.  In  assembling 
the  required  configuration  from  the  CGSI 
building  blocks,  the  modularity  and  con¬ 
figurability  of  the  CGSI  components  to¬ 
gether  with  standardized  inter-card  and 
inter-channel  interface  minimize  new  de¬ 
sign.  Correlated  hardware,  software  and 
firmware  components  also  ease  the  config¬ 
uration  process.  Despite  this  modularity. 


Life  Cycle  Support ■  A  key  element  of 
any  trainer  application  is  the  life  cycle 
support  requirements  of  the  system.  This 
normally  includes  maintenance  and  spare 
issues.  Increasingly,  especially  for 
software  intensive  applications,  this  has 
meant  the  enhancement  or  redirection  of  a 
trainer  for  new  training  requirements 
related  to  new  tactics,  new  equipment 
(Avionics,  Visionic  Weapons  Systems),  and 
new  personnel  qualifications.  Historical¬ 
ly,  visual  systems  have  had  extensive  data 
base  maintenance  costs  and  infrequent  but 
extensive  hardware/software  upgrades. 
CGSI  promises  significant  improvements  in 
all  of  these  areas:  1)  Maintenance  -  On¬ 
line  BITE,  and  extensive  isolation  are 
included.  2)  Spares  -  Few  card  types 
minimize  replacement  cost  as  well  as 
lowering  stores  inventory.  3)  New  Train¬ 
ing  Requirements  -  Common  building  blocks 
permit  multiple  use  of  CGSI  systems  and 


Figure  7.  CGSI  Simulated  Periscope 
Image 


Figure  8.  Small  CGSI  Configuration 
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goals.  3)  Team  tactics  trainers  -  Systems 
providing  coordination  training  involving 
multiple  vehicles  and/or  ground  personnel 
are  easily  configured.  4)  Existing  CGI 
visual  retrofit  -  Typical  CGI  systems  of 
today  exhibit  inadequate  target  fidelity 
and  very  limited  background  fidelity  or  a 
serious  compromise  of  both.  CGSI  can  be 
used  to  supplement  such  systems  requiring 
higher  fidelity. 


CONCLUSION 

CGSI  is  a  viable  approach  to  visual 
and/or  sensor  simulation  in  multiple 
applications  ranging  from  the  very  small 
to  the  extremely  large.  It  is  clearly 
warranted  when  high  object  fidelity  and/or 
high  data  base  flexibility  is  required. 
It  can  readily  support  multiple  sensors  in 
integrated  operation  including  special 
effects  from  multiple  viewpoints.  It  is 
capable  of  providing  specific  area  simula¬ 
tions  with  full  freedom  of  motion  for  both 
own  ship  friendly  vehicle  and  hostile 
targets,  and  supports  Trackers  and 
Weapons,  with  high  Gaming  area  flexibility 
and  large  environment  variations.  The 
next  critical  milestone  in  this  CGSI  de¬ 
velopment  is  the  demonstration  of  a  lim¬ 
ited  multiple  pipeline  configuration  (4 
pipelines)  integrated  with  all  of  the 
modules  outlined  in  the  block  diagram  in 
Figure  1.  This  demonstration  is  scheduled 
for  April  1984. 
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ABSTRACT 

The  training  effectiveness  of  the  camera-modelboard  visual  system  for  low-altitude,  nap- 
of-the-earth  (NOE)  flights,  particularly  for  helicopters,  is  well  established.  Traditional 
camera-modelboard  technology,  however,  has  a  number  of  inherent  limitations  which  have  been 
overcome  by  using  a  laser  image  generator  instead  of  a  TV  camera  as  in  the  current  genera¬ 
tion  of  camera-modelboard  systems.  The  first  full-scale  Laser  Image  Generation  (LIG)  visual 
system,  developed  by  Singer-Link  under  the  AH-1S  Cobra  Helicopter  Flight  Weapons  Simulator 
contract,  will  be  delivered  to  the  U.S.  Army  in  the  near  future.  This  new  visual  system 
offers  improvements  in  many  areas,  some  of  which  are  discussed  in  this  paper,  together  with 
the  visual  system  technology  involved  and  performance  parameters  achieved  on  the  AH-1  S 
simulator. 


INTRODUCTION 

The  effectiveness  of  helicopter  weapons 
system  and  flight  trainers  employing  modern 
flight  simulation  technology  depends  greatly  on 
the  ability  to  provide  the  pilot-trainee  with  a 
suitable  visual  environment  in  the  simulator. 
This  is  particularly  true  for  low-altitude, 
nap-of-the-  earth  (NOE)  flight  training,  where 
sufficient  scene  content  and  high  scene  detail 
are  needed  to  provide  the  necessary  out-the- 
window  (OTW)  visual  cues.  It  is  well  estab¬ 
lished  that  these  types  of  training  cues  can  be 
adequately  provided  by  visual  systems  employing 
television  cameras  that  view  terrain  models. 
However,  the  traditional  TV-based  camera- 
modelboard  visual  systems  have  several  drawbacks 
which  have  made  them  less  attractive  when  com¬ 
pared  to  other  maturing  products  for  visual 
simulation. 

One  inherent  limitation  of  the  first-gener¬ 
ation  camera-modelboard  image  generator  was  in 
the  camera  pickup  tube,  which  typically  had 
"third-field"  image  lags  of  20-25  percent.  This 
resulted  in  image  smearing  when  dynamic  scene 
conditions  were  encountered.  This  effect  typ¬ 
ically  occurs  when  the  simulated  aircraft  atti¬ 
tudes  are  changing  rapidly. 

Another  limitation  was  due  to  the  limited 
detail  response  of  image  pickup  tubes  which 
reduces  the  percentage  modulation  of  the  scene 
details  displayed  to  the  student-trainee. 

A  third  limitation  was  the  degree  of  image 
tube  sensitivity  achievable  in  conjunction  with 
the  other  requirements  of  resolution,  signal-to- 
nolse  ratio,  lag,  etc.,  needed  for  simulator 
applications.  Since  great  depth  of  focus  is 
required  in  camera-modelboard  systems,  the  opti 
cal  probe  coupled  to  the  camera  usually  has  a 
very  small  relative  aperture  and  transmits  very 
little  light.  The  net  effect  is  that  a  very 
high  light  level  is  needed  to  adequately 
illuminate  the  model  board. 

In  short,  although  the  traditional  camera- 
modelboard  visual  system  provides  excellent  OTW 
visual  cues  for  NOE  flight  training,  it  has 
limited  dynamic  resolution,  provides  a  somewhat 


"soft"  picture,  and  consumes  a  great  deal  of 
energy. 

To  overcome  these  limitations  while  retain¬ 
ing  the  desirable  features  of  the  camera-model¬ 
board  system,  an  IR&D  program  was  conducted 
jointly  by  the  Link  and  Librascope  Divisions  of 
The  Singer  Company  to  develop  a  new  image  gener¬ 
ator  that  uses  a  laser  beam  to  scan  a  terrain 
model  board.  The  IR&D  program  culminated  in  a 
feasibility  model  that  was  demonstrated  to  the 
U.S.  Army.  Subsequently ,  a  decision  was  made  by 
the  U.S.  Army/PM  TRADE  to  implement  the  Laser 
Image  Generator  (LIG)  on  the  AH-1  S  Cobra  Weapon 
System  Trainer  production  contract,  with  the 
first  simulator  scheduled  for  training  by  early 
1984. 


AH-1 S  COBRA  PRODUCTION  SIMULATOR 

The  AH-1S  Cobra  production  simulator  has  two 
separate  cockpit  trainee  stations,  one  for  the 
pilot  and  one  for  the  copilot-gunner  (CPG).  The 
pilot's  station  is  equipped  with  two  adjacent 
display  windows,  one  front  window  and  one  side 
window,  each  with  a  48°  horizontal  by  36°  verti¬ 
cal  field  of  view  (FOV).  The  CPG’s  station  is 
supplied  with  only  a  single  front  window  display. 

Two  separate  LIG  systems,  each  with  a  model  - 
board,  provide  two  image  channels  that  are 
switchable  to  either  of  the  two  forward  display 
windows.  The  exact  channel -to-di spl ay  alloca¬ 
tion  depends  on  the  training  mode  selected  by 
the  instructor.  When  the  integrated  training 
mode  is  selected,  the  pilot  and  CPG  stations 
operate  in  unison  and  the  two  LIG  channels  are 
available  to  both  of  the  pilot's  displays.  In 
this  mode,  the  front  channel  is  repeated  for  the 
CPG  station  also.  In  the  independent  mode  of 
training,  the  pilot  and  the  CPG  each  operate,  in 
effect,  a  separate  simulator,  and  a  LIG  visual 
system  is  available  to  each  trainee. 

The  visual  system  provides  a  gaming  area  of 
approximately  10.5  by  4.5  nautical  miles  with 
terrain  features  designed  for  the  required  Cobra 
helicopter  training  missions,  including  NOE 
flight  and  confined  area  landings. 


LIG  SYSTEM  CONFIGURATION 

An  artist's  conception  of  the  Laser  Image 
Generator  is  shown  in  Figure  1,  and  a  simplified 
block  diagram  of  the  LIG  system  is  provided  in 
Figure  2.  A  single  LIG  channel  will  De  discussed 
here  to  describe  the  system  configuration  and 
principles  of  operation. 

The  major  difference  between  the  LIG  visual 
system  and  the  convent ional  camera-model  board 
system  is  the  replacement  of  the  television 
camera  with  a  laser  image  generator  consisting 
of  a  laser  table,  a  laser  transmission  subsystem, 
and  a  laser  scanning  unit  mounted  on  the  gantry. 
Also,  the  bank  of  lights  that  is  required  to 
illuminate  the  terrain  modelboard  is  replaced 


with  a  bank  of  photomultiplier  tubes  (PMT's)  for 
image  pickup.  The  AH-1S  LIG  system  consists  of: 

1)  A  laser  table  light  source 

2)  Laser  beam  transmission  subsystem 

3)  Laser  scanning  unit 

4)  Optical  projection  probe  with 
Scheimpflug  tilt/focus  correction 

5)  Gantry  transport 

6)  24-foot  by  64-foot  terrain  modelboard 
scaled  at  1000:1 

7)  Photomultiplier  tube  bank 

8)  Video  signal  processing 

9)  Special  effects,  including  cultural 
1 ights 

10)  Color  CRT  infinity  displays 


Figure  1  ARTIST'S  CONCEPTION  OF  LASER  IMAGE  GENERATOR  (LIG) 


CULTURAL 

LIGHTING 

PROCESSOR 

RGB 


SUMMING 

ANO 

PROCESSOR 


i 

CULTURAL 

LIGHTING 

o 

J 

PICKUP 

oc 

< 

o 

m 

WEAPONS 
EEffCTS 
l.ENf  HATOR 


GANTRY  1 

PROBE  I 

SCANNER  2 


■ 


ELECTRONICS 

CABINET 


Figure  2  LIG  SYSTEM  BLOCK  DIAGRAM  (SINGLE  CHANNEL) 


PRINCIPLES  OF  LIG  OPERATION 


As  in  a  TV  camera-model  board  visual  system, 
the  LIG  system  generates  a  picture  by  viewing  a 
scaled  terrain  modelboard.  The  source  of  illu¬ 
mination  for  the  modelboard  is  the  laser  beam. 

As  shown  in  Figure  3,  the  laser  beam  originates 
at  the  laser  table  and  is  directed  along  the 
rail  on  which  the  gantry  is  transported,  tra¬ 
versing  the  modelboard  in  the  long  (X)  axis.  At 
the  gantry  location,  the  laser  beam  is  trans¬ 
mitted  up  the  gantry,  along  the  short  modelboard 
axis  (Y).  Here,  the  laser  beam  is  relayed  onto 
the  gantry-mounted  laser  scanning  unit  which 
forms  a  scanning  raster  by  deflecting  the  beam 
horizontally  and  vertically.  The  laser  scanning 
raster  is  projected  through  the  probe  onto  the 
modelboard,  illuminating  the  area  defined  by  the 
FOV,  as  seen  from  the  trainee's  eyepoint.  The 
gantry  positions  the  simulated  eyepoint  to  the 
correct  X,  Y,  and  Z  coordinates,  while  the  probe 
optics  provide  the  roll,  yaw,  and  pitch  of  the 
simulated  aircraft. 

The  scattered,  reflected  light  from  the 
modelboard  is  picked  up  by  the  bank  of  PMT's, 
each  sensing  the  reflected  light  simultaneously 
with  the  others  and  generating  an  output  elec¬ 
trical  signal.  The  outputs  from  all  the  PMT's 
are  then  summed,  producing  a  single  time-varying 
video  signal  as  the  gantry  duplicates  the  flight 
path  of  the  simulated  aircraft.  This  video  sig¬ 
nal  is  equivalent  to  the  signal  generated  by  the 
television  image  pickup  tubes  and  preamplifiers 
of  the  conventional  camera-modelboard  system. 

The  video  signal  is  used  as  an  input  to  the  main 
video  processor  where  the  special  effects,  in¬ 
cluding  sky,  horizon,  visibility,  and  weapons  ef¬ 
fects,  are  inserted.  The  signal  levels  are  then 
properly  scaled  to  drive  the  displays  in  the 
simulator  cockpit.  The  display  raster  and  the 
laser  scanning  raster  are  synchronized  so  that 
as  the  laser  beam  scans  a  picture  element  on  the 
modelboard,  the  display  CRT  addresses  the  corre¬ 
sponding  picture  element  in  the  display  raster. 

Cultural  lighting  is  simulated  by  implanting 
properly  scaled  fiber  optics  in  the  modelboard 
as  in  conventional  camera-modelboard  systems. 

The  signals  from  the  fibers,  however,  are  picked 
up  by  PMT's  that  are  located  behind  the  model- 
board  and  away  from  the  main  PMT  bank.  The 
cultural  lighting  signal  is  separate  from  the 
model  terrain  information  and  can  be  processed 
independently.  This  processing  flexibility  per¬ 
mits  cultural  lights  to  be  brilliantly  displayed 
against  a  darkened  terrain  background  under  tac¬ 
tical  night  flight  training  conditions. 

DESCRIPTION  OF  LASER  IMAGE  GENERATOR  COMPONENTS 

The  Singer-Link  LIG  system  development  took 
full  advantage  of  proven  camera-modelboard  hard¬ 
ware  such  as  the  servoed  gantry  system,  the 
terrain  modelboard,  and  the  Farrand  60°  Scheim- 
pflug  optical  probe  modified  for  laser  projec¬ 
tion.  The  major  components  that  required  design 
and  development  effort  are  those  related  to  the 
laser  image  generation  process.  The  new  subsys¬ 
tems  are  the  laser  table,  the  laser  beam  trans¬ 
mission  system,  the  laser  scanning  unit,  and  the 
PMT  bank. 


Figure  3  LASER  BEAM  TRANSMISSION  SYSTEM  SCHEMATIC 


Laser  Table 

The  laser  table  is  an  optical  bench  where 
three  laser  beams  are  combined  to  provide  a 
single,  concentric  "white  light"  beam  consisting 
of  four  major  laser  spectral  lines  with  the 
following  frequencies: 

Blue  457.9  nm  and  476.5  nm 

Green  514.5  nm 

Red  647.1  nm 

Because  it  is  not  practical  to  mount  the  laser 

table  directly  on  the  gantry,  it  is  located  on 
the  floor. 

Two  ion  lasers  are  used  to  provide  the  needed 
colors.  An  argon  laser  generates  the  blue  and 
green  lines  and  a  krypton  laser  supplies  the  red 
line.  Each  ion  laser  is  equipped  with  a  self¬ 
regulating  light  control  system  that  monitors 
the  laser  output  and  maintains  it  at  a  preset 
level . 

The  optical  arrangement  for  the  laser  tabic 
is  shown  in  Figure  4.  Notice  that  each  laser 
beam  is  individually  shuttered  to  permit  easy 
alignment  and  maintenance.  Three  beam  con¬ 
troller  units  are  provided,  one  for  each  laser 
color.  Each  beam  controller  performs  the 
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size  for  transmission  to  the  gantry  and  provides 
adjustments  for  zoom,  focus,  and  angular  steer¬ 
ing.  The  beam  expansion  is  set  up  so  that  a 
beam  "waist"  is  achieved  for  each  color  at  a 
fixed  distance  from  the  table.  The  zoom 
adjustment  controls  the  optical  invariant  of 
each  color  so  that  the  three  color  beams  will 
match  in  size  and  divergence.  The  focus  adjust¬ 
ment  shifts  the  waist  of  the  beam  along  the 
transmission  axis.  It  also  compensates  for  the 
small  residual  spherical  power  in  each  optical 
path.  The  angular  steering  adjustment  provides 
color  convergence  at  infinity  for  the  three 


the  pupil  position  is  not  affected.  With  the 
colors  converged  at  both  the  pupil  and  infinity, 
the  color  is  converged  for  any  gantry  position. 

The  three  beams  of  color  are  combined  into  a 
single  coaxial  beam  before  being  transmitted 
through  the  periscope,  where  the  composite  beam 
is  aligned  in  angle  and  translational  displace¬ 
ment  so  that  it  matches  the  gantry  rail  align¬ 
ment.  Routine  maintenance  and  alignment  checks 
are  greatly  facilitated  by  the  use  of  a  built-in 
optical  test  channel.  Figure  5  is  a  photograph 
of  the  production  laser  table. 


Figure  5  PRODUCTION  LASER  TABLE  HARDWARE 
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Laser  Beam  Transmission  System 

One  of  the  technical  challenges  met  by  the 
LIG  system  design  was  the  design  of  a  system  to 
transmit  the  laser  beam  from  the  laser  table  to 
the  moving  gantry-mounted  laser  scanning  unit. 

The  resulting  transmission  system  design  accom¬ 
modates  all  gantry  motions  expected  under  normal 
simulator  operations  and  maintains  correct  laser 
beam  pointing  to  within  acceptable  tolerances. 

The  design  accommodates  a  transmission  path  that 
varies  greatly  in  length,  depending  on  gantry 
position.  The  desired  results  have  been  achieved 
by  expanding  the  laser  beam  from  the  nominal  beam 
size  of  1.3  mm  to  the  chosen  beam  waist  diameter 
and  then  routing  the  beam  along  the  X-axis,  up 
the  Y-axis  gantry  tower,  along  the  2-axis,  and 
into  the  entrance  pupil  of  the  scanning  unit. 

Expansion  of  the  beam  for  transmission  is 
done  for  several  reasons.  First,  over  a  long 
transmission  path,  the  laser  beam  diameter  would 
increase  as  a  result  of  diffraction  dispersion, 
with  the  percentage  increase  a  function  of  the 
beam  diameter  as  well  as  the  transmitted  dis¬ 
tance.  Small  beams  expand  very  rapidly,  large 
beams  more  slowly.  For  the  chosen  transmission 
beam  size,  variation  in  beam  diameter  over  the 
total  travel  distance  is  less  than  6  percent. 

This  is  well  within  the  limits  established  by 
optical  aperture  design  considerations  and  the 
system  resolution  requirement  which  is  dependent 
on  the  spot  size  of  the  scanning  laser  beam.  A 
second  advantage  of  the  expanded  beam  is  that 
any  lateral  displacements  of  the  beam  caused  by 
gantry  motion  are  of  a  smaller  percentage  as 
compared  to  the  increased  beam  diameter,  so  that 
mot  ion- induced  displacements  of  the  beam  have  a 
smaller  effect  on  beam  movement  at  the  probe 
exit  pupil. 


On  the  other  hand,  if  the  size  of  the  trans¬ 
mission  beam  is  too  large,  problems  will  be 
caused  by  wave  front  distortions  which  are  exag¬ 
gerated  when  the  large  beam  is  reduced  back  to 
the  small  size  required  to  generate  the  scanning 
raster.  In  addition,  a  large  beam  reduction 
ratio  would  result  in  a  large  magnification  of 
beam  pointing  angular  errors  introduced  in  the 


transmission  process.  Even  at  the  chosen  beam 
diameter  and  beam  reduction  ratio,  the  residual 
beam  pointing  error  at  the  entrance  pupil  of  the 
laser  scanning  device  would  be  unacceptable 
without  correction.  A  beam  correction  servo  is 
incorporated  into  the  design  of  the  gantry- 
mounted  scanning  unit,  as  described  below. 

Laser  Scanning  Unit 

The  expanded  laser  beam  is  transmitted  from 
the  laser  table  and  received  by  the  gantry- 
mounted  laser  scanning  unit.  This  unit  gener¬ 
ates  the  actual  scanning  raster  prior  to  its 
projection  onto  the  model  board  via  the  Scheim- 
pflug  optical  probe.  In  preparation  for  scan¬ 
ning,  the  transmitted  laser  beam  is  reduced  in 
diameter  and  the  residual  angular  (pointing) 
errors  are  removed.  As  shown  in  Figure  6,  this 
is  accomplished  by  first  routing  the  beam 
through  a  reducer  which  converts  the  beam  diam¬ 
eter  back  to  1.3  mm  and  then  using  beam  position 
sensors  to  detect  beam  pointing  errors  in  two 
orthogonal  directions.  Each  position  sensor 
consists  of  a  beamsplitter  that  diverts  a  small 
amount  of  laser  light  (less  than  1  percent)  onto 
the  optical  sensor  (a  silicon  lateral-effect 
photodiode)  via  imaging  optics.  The  error  sig¬ 
nals  generated  are  used  to  drive  two  beam-steer¬ 
ing-correction  galvanometers,  one  for  each  of 
the  two  perpendicular  axes,  as  a  feedback  system 
to  achieve  the  calibrated  null  position. 

The  corrected  laser  beam  is  directed  to  the 
rotating  head  of  the  high-speed  scanner  where  it 
is  deflected  by  a  polygon  mirror,  made  up  of  24 
facets,  rotating  at  approximately  76,000  revolu¬ 
tions  per  minute.  Since  air  bearings  are  used 
for  the  rotating  polygon,  a  support  system  con¬ 
sisting  of  an  air  compressor,  holding  tank,  and 
vacuum  pump  is  required,  along  with  a  small 
water  cooling  unit  to  remove  heat  generated.  A 
fail-safe  interlock  system  is  provided  to  pro¬ 
tect  the  high-speed  scanner.  The  exit  beam  from 
the  scanner  facet  provides  the  horizontal  (or 
fast)  sweep  of  the  scanning  raster.  The  ver¬ 
tical  or  slow  sweep  is  provided  by  a  galva¬ 
nometer  driven  at  the  60-hertz  field  rate,  de¬ 
flecting  the  relayed  output  beam  from  the  high¬ 
speed  scanner  to  provide  the  vertical  sweep. 


Figure  6  LASER  SCANNING  UNIT 
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A  laser  scanning  raster  is  therefore  formed 
at  the  entrance  pupil  of  the  optical  probe,  cor¬ 
responding  to  the  displayed  field  of  view  of  a 
single  window  (scaled  for  48  degrees  horizontal 
by  36  degrees  vertical).  The  scanning  laser 
beam  is  projected  onto  the  modelboard,  illumi¬ 
nating  only  what  is  within  the  FOV,  as  seen  from 
the  simulated  eyepoint.  The  production  AH-1S 
laser  scanning  unit  is  shown  in  Figure  7. 


Figure  8  PMT  ARRAY  AND  MODULE 


The  AH-1S  PMT  bank  design  of  44  sites  repre 
sents  a  reasonable  compromise  among  performance 
parameters  such  as  S/N  ratio  and  signal  uniform 
ity  versus  the  number  of  PMT  sites  required, 
which  would  directly  impact  hardware  complexity 
and  cost.  Performance  specifications  were 
established  for  a  S/N  ratio  of  40  decibels  or 
better,  and  a  design  objective  was  set  to  have 
typically  no  more  than  a  15  percent  signal  am¬ 
plitude  variation  caused  by  shadows.  The  PMT 
bank  was  designed  to  meet  these  requirements. 


Figure  7  PRODUCTION  LASER  SCANNING  UNIT  HARDWARE 
PMT  Bank 

The  light  reflected  by  the  terrain  model  is 
picked  up  by  the  PMT  bank,  which  generates  the 
video  signal  for  electronic  processing  and  dis¬ 
play.  The  PMT  bank  consists  of  arrays  of  PMT 
sites,  arranged  as  four  rows  by  eleven  columns 
and  staggered  as  shown  in  Figure  8  to  provide 
uniform  signal  distribution.  Each  PMT  site 
contains  a  triad  of  2-inch  PMT's  clustered  in  a 
triangular  pattern.  A  red,  green,  and  blue 
color  filter  is  provided,  one  for  each  tube  in 
the  triad,  to  give  a  three-primary  (red-green- 
blue)  color  system.  Selection  of  the  color 
filters,  transmission  optics,  and  modelboard 
paints,  together  with  the  chosen  laser  wave¬ 
lengths,  was  originally  made  after  comprehensive 
colorimetry  analysis,  supported  by  empirical 
results.  The  choice  of  colors  has  since  proved 
to  be  very  satisfactory  on  the  full-scale  pro¬ 
duction  system. 


Figure  9  AH-1S  LIG  MODELBOARD/GANTRY  SYSTEM 


LIG  PERFORMANCE  RESULTS 

The  first  production  AH-1S  LIG  visual  system 
has  been  undergoing  system  integration  and  test 
for  some  time  and  is  being  prepared  for  U.S. 

Army  acceptance.  Preliminary  results  show  that 
all  the  performance  specifications  for  the  LIG 
are  met,  and  often  exceeded.  The  quality  of  the 
picture  on  the  production  unit  is  superior  even 
to  that  achieved  on  the  laboratory  prototype. 
Although  a  formal  reliability  and  maintainability 
(RAM)  assessment  and  demonstration  is  yet  to  be 
conducted,  experience  accumulated  on  the  new 
visual  system  so  far  indicates  that  significant 
RAM  improvements  over  previous-generation  camera- 
modelboard  systems  have  been  achieved.  In  addi¬ 
tion,  the  test  results  show  superior  performance 
in  many  important  areas,  as  discussed  below. 


Dynamic  Resolution 

Static  limiting  resolution  measurements 
taken  on  the  production  LIG  system  show  better 
than  6  arc  minutes  per  optical  line  pair  (OLP), 
only  a  slight  improvement  over  the  7  arc 
minutes/OLP  on  previous  camera-model  board  sys¬ 
tems.  However,  image  lag  effects  are  absent  in 
the  LIG  system,  except  for  the  negligible  ef¬ 
fects  of  very  short  decay  time  for  the  display 
phosphor.  For  the  LIG,  therefore,  the  dynamic 
resolution  is  the  same  as  the  static  resolution, 
resulting  in  a  dramatic  improvement  for  dynamic 
scenes  with  fast-moving  objects. 

S/N  Ratio 

A  S/N  ratio  of  better  than  40  decibels  has 
been  measured  for  each  color  channel,  with  the 
argon  and  krypton  lasers  operating  at  less  then 
half  the  rated  output  power.  This  allows  a  two¬ 
fold  increase  in  laser  power  to  further  improve 
the  S/N  ratio  or  operation  at  one-half  power  to 
prolong  their  useful  life  and  increase  reli¬ 
ability. 

Picture  Contrast 

In  addition  to  the  improved  dynamic  resolu¬ 
tion,  the  detail  response  of  the  image  (or  the 
modulation  transfer  function,  MTF,  of  the  sys¬ 
tem)  is  significantly  enhanced,  particularly  in 
the  low  and  middle  frequency  regions.  This 
translates  directly  into  a  more  vivid  picture, 
remarkable  for  a  TV  system,  which  will  greatly 
enhance  the  training  value  of  the  LIG-equipped 
simulator.  The  enhancement  is  achieved  primar¬ 
ily  because  limitations  previously  posed  by  the 
camera  pickup  tube  have  been  removed.  With 
properly  designed  laser  optics,  the  system  reso¬ 
lution  and  MTF  are  now  constrained  by  other  sys¬ 
tem  components,  such  as  the  optical  probe  and 
the  display  CRT. 

Color  Rendition 

The  subject  of  color  rendition  using  only 
three  discrete  laser  lines  has  been  given  much 
attention  throughout  the  LIG  development  effort. 
Starting  with  the  original  colorimetry  analysis, 
continuing  through  the  feasibility  model  empiri¬ 
cal  verifications,  and  finally  culminating  with 
the  production  design,  choices  were  carefully 
made  in  selecting  every  component  that  would 
affect  the  final  color  presentation.  The  end 
product  offers  an  exceptional,  high-quality 
color  image. 

Color  Registration 

Free  of  the  difficulties  associated  with 
registering  a  color  camera,  particularly  at  the 
corners  of  the  picture,  the  LIG  offers  a  sharply 
registered  picture.  Color  misregistration  could 
result  if  the  red,  green,  and  blue  laser  beams 
become  misaligned,  but  this  does  not  happen 


under  normal  conditions  because  the  optical 
system  for  the  composite  laser  beam  is  a  simple 
and  stable  design,  and  the  optical  elements  are 
used  primarily  on-axis.  The  Farrand  Optical 
probe,  fully  color-corrected,  performs  well  for 
the  selected  laser  frequencies,  which  are  within 
its  original  design  capabilities  (broadband 
television  camera  applications). 

Energy  Consumption 

The  final  significant  improvement  is  in  the 
reduced  energy  requirement  for  the  LIG.  Since 
the  laser  illuminates  only  what  is  within  the 
FOV,  no  energy  is  wasted  on  lighting  what  the 
pilot-trainee  cannot  see,  and  power  consumption 
is  reduced  by  more  than  80  percent.  Compared  to 
the  previous  camera-model  board  systems  utilizing 
high-intensity  lamp  banks,  the  80-percent  energy 
reduction  is  quite  attractive.  Removing  the 
lamp  bank  eliminates  almost  200  kilowatts  of 
power  per  model  board,  plus  the  corresponding 
reduction  in  facilities  air-conditioning  needed 
to  remove  the  heat  generated. 

As  examples  of  the  picture  quality  provided 
by  the  LIG  visual  system,  photographs  of  typical 
AH-1S  display  scenes  are  shown  in  Figures  10  and 
11.  A  summary  of  LIG  system  performance  speci¬ 
fications  and  preliminary  test  results  is  given 
in  Table  1 . 

CONCLUSION 

The  first  AH-1S  Cobra  simulator  to  be 
equipped  with  a  LIG  visual  system  will  be 
delivered  to  the  U.S.  Army  in  the  spring  of 
1984.  The  laser  image  generation  visual  system 
offers  improvements  over  the  traditional  camera- 
model  board  system  in  many  areas,  including  a 
more  vivid  picture  (higher  detail  modulation), 
freedom  from  picture  smearing  caused  by  image 
lag,  improved  picture  registration,  and  signifi¬ 
cantly  reduced  energy  consumption.  The  LIG  sys¬ 
tem  provides  very  high  scene  detail  and  modeling 
fidelity.  It  offers  an  attractive  solution  to 
those  training  needs  where  visual  cues  of  this 
nature  are  required  for  effective  training. 
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Figure  10  AH-1S  LIG  DISPLAY  SCENE  OF  A  WEAPONS  DELIVERY  AREA 


Figure  11  TYPICAL  AH-1S  LIG  DISPLAY  SCFN[ 
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ABSTRACT 


Wide  field  of  view,  high  resolution,  detailed  visual  displays  are  crucial  for  the 
effective  simulation  of  complex  air-to-air  and  air-to-ground  combat  environments.  Current 
dome  and  dodecahedron  systems  are  far  too  costly  and  lack  the  combination  of  required 
capabilities.  The  Air  Force  Human  Resources  Laboratory  (AFHRL)  is  currently  developing  a 
fiber  optic  helmet  mounted  display  { FOHMD )  system  which  has  the  potential  for  filling  these 
demanding  requirements.  The  breadboard  FOHMD,  built  through  a  Canadian  cost-sharing 
contract  with  CAE  Electronics,  displays  a  head-slaved  high  resolution  area  of  interest 
surrounded  by  a  low  resolution  background  in  color.  The  instantaneous  field  of  view  is 
comparable  to  the  view  available  to  a  pilot  when  wearing  an  Air  Force  helmet.  Four  image 
generation  channels  and  projectors  are  used  to  generate  individual  displays  for  each  eye. 

The  imagery  is  piped  to  the  helmet  via  coherent  fiber  optic  bundles.  This  system  is  a 
valuable  research  tool  for  studying  many  of  the  issues  associated  with  helmet  mounted 
displays  such  as  image  stability,  resolution/brightness/field  of  view  trade-offs,  and  visual 
perception/fatigue,  A  follow-on  phase  will  refine  the  basic  breadboard  design  by  reducing 
the  number  and  srze  of  fiber  optic  bundles,  developing  improved  helmet  tracking  and  refined 
optics,  and  researching  a  multi-mission  instructor/operator  station.  The  fiber  optic  helmet 
mounted  display  shows  outstanding  potential  and  may  ultimately  be  the  key  to  high  fidelity 
combat  simulation  training  at  the  squadron  level. 


INTRODUCTION 

Aircraft  simulators  have  become  an  integral 
part  of  both  military  and  civilian  flight 
training.  Initially  simulation  training  was 
limited  to  instrument  or  emergency  procedures 
training  because  of  the  difficulty  in 
simulating  out-the-window  scenes.  Technical 
developments  in  computer  image  generation  (CIG) 
displays  have  provided  a  means  to  achieve 
visual  simulation.  CIG  is  now  widely  used  in 
flight  simulation  to  train  takeoffs  and 
landings  in  fixed  wing  aircraft.  A  few 
military  research  simulators  have  successfully 
demonstrated  that,  in  wide  field  of  view  (FOV) 
flight  simulators,  significant  improvements  can 
also  be  observed  in  offensive  and  defensive 
combat  skills  practiced  in  simulated  threat 
environments. 

A  recent  research  study  on  the  transfer  of 
training  from  the  Advanced  Simulator  for  Pilot 
Training  (ASPT)  A-10  cockpit  to  actual  flight 
performance  in  Red  Flag  exercises  provided 
"empirical  evidence  that  training  under  high 
density  ground  threat  conditions  in  a  flight 
simulator  can  improve  the  survivability  of 
aircrews  in  a  combat-like  environment" .( 1 ) 
Historical  experience  from  major  conflicts  has 
shown  that  the  first  few  missions  a  pilot  flies 
are  the  most  critical  for  his  survival.  After 
those  first  few  missions,  a  pilot's 
survivability  significantly  increases. (2) 

The  demonstrated  transfer  of  training  coupled 
with  historical  combat  data  are  a  strong 
argument  that  combat  simulation  training  can 
become  a  force  multiplier  by  providing  pilots 
with  up  to  the  fourth  or  fifth  mission  level  of 
experience  before  going  into  battle.  The 
strong  potential  impact  combat  simulation  can 
have  on  survivability  mandates  the  development 
of  full  visual  flight  simulation. 


Although  wide  field  of  view  simulators  have 
been  produced  for  research  purposes,  they 
remain  prohibitively  expensive  for  widespread 
distribution  and  lack  the  combination  of 
critical  capabilities  needed  for  full  combat 
simulation.  Demonstrated  approaches  to  wide 
field  of  view  simulation  use  either  dome 
projection  systems  or  dodecahedron  mosaic 
cathode  ray  tube  (CRT)  displays  to  surround  the 
pilot  with  imagery.  These  types  of  systems 
lack  the  required  combination  of  field  of  view, 
resolution,  brightness,  and  short  throughput 
delay  needed  to  simulate  air-to-ground, 
air-to-air,  multi-participant  scenarios.  In 
light  of  this  fact,  both  the  Air  Force  and  the 
Navy  are  pursuing  alternate  technology 
development  programs  to  overcome  these 
obstacles.  Research  efforts  are  beginning  to 
take  advantage  of  the  increases  in  performance 
which  can  be  achieved  through  the  use  of  area 
of  interest  (AOI)  displays  which  are  head,  eye, 
and/or  target  slaved.  AOI  displays  need  only 
project  the  "instantaneous"  image  currently 
within  the  pilot's  FOV.  This  significantly 
reduces  the  area  of  imagery  which  must  be 
generated  at  any  one  instant.  AOI  displays  can 
inherently  attain  higher  resolution,  higher 
brightness,  and  more  scene  detail  than 
conventional  systems  because  of  the  narrower 
FOV  which  is  required. 

The  Air  Force  Human  Resources  Laboratory 
(AFHRL)  has  had  many  years  of  experience  with 
AOI  displays.  This  experience  includes:  1) 
the  Simulator  for  Air-to-Air  Combat  which  uses 
a  target-slaved  high  resolution  raster  inset, 

2)  the  High  Resolution  Area  (HRA)  Dual 
Projector  Display  system  which  has  demonstrated 
a  target-slaved  high  resolution  inset  using 
light  valve  projectors,  3)  head-slaved  AOI 
research  studies  in  the  ASPT'3),  and  4)  a 
head-slaved  dual  CRT  helmet  mounted  display 
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FOHMD  SYSTEM  DESCRIPTION 


system.  AFHRL  research  has  supported  the  view 
that  AOI  displays  are  applicable  to  tactical 
simulation  and  has  continued  development  in 
this  area  with  a  new  visual  display  system,  the 
Fiber  Optic  Helmet  Mounted  Display  (FOHMD). 

This  system  is  currently  being  developed  by  CAE 
Electronics  Ltd.  through  a  joint  US-Canada  cost 
sharing  program.  The  breadboard  FOHMD  has  been 
delivered  to  AFHRL  and  has  already  been 
demonstrated  in  limited  form.  The  performance 
of  this  breadboard  system  indicates  outstanding 
potential  for  providing  high  fidelity  combat 
simulation  at  an  affordable  cost. 


The  FOHMD  (Figure  1  and  Figure  2)  presents 
the  pilot  with  a  head-slaved  instantaneous 
field  of  view  comparable  to  that  of  a  standard 
USAF  helmet.  In  the  center  of  this  field  of 
view  is  a  fixed  high  resolution  inset.  Only 
four  channels  of  color  computer  generated 
imagery  are  needed  to  produce  this 
instantaneous  field  of  view  which  is  slewable 
over  the  entire  360  degrees.  Light  valve 
projectors  project  the  display  through  coherent 
fiber  optic  bundles  to  the  helmet.  System 
goals  (Table  1)  include  high  resolution  and 
high  brightness  while  maintaining  wide  field  of 
view  and  reduced  CIG  channel  requirements. 


TABLE  1 

FOHMD  SYSTEM  PERFORMANCE  GOALS 


Parameter 


Goal 


Total  Field  of  View 
Resolution 

Displayed  Instantaneous  FOV 
Displayed  High  Resolution  FOV 
Inset  Resolution 
Background  Resolution 
Apparent  Luminance 
Color 


Limited  Only  by  Cockpit  Structure 
2-3  Arc  Minute/Pixel 
1 35°  x  600 
250  or  400 

1 . 5  Arc  Mi nute/Pi xel 
5.0  Arc  Minute/Pixel 
80  Foot-Lamberts 
Full 


PROJECTORS 


FIBER  OPTIC 
CABLES 


HEAD  DISPLAY 


^  IMAGE 
GENERATOR 


HEAD  POSITION 
SENSOR 


FIGURE  2.  FOHMO  SYSTEM  DISPLAY 


The  complex  combat  tasks  of  low  altitude 
flight,  target  acquisition,  weapon  delivery, 
threat  avoidance  and  confined  area  maneuvering 
require  a  high  resolution  visual  display.  At 
2-3  miles,  even  an  artificially  enlarged  target 
disappears  between  the  raster  lines  of  a  six 
arc -minute  1024  line  display  such  as  ASPT's. 

To  achieve  realistic  combat  conditions,  a 
visual  scene  must  be  comparable  to  the 
resolution  of  the  human  eye:  1-2  arc-minutes. 
Dr  A.  M.  Spooner  has  noted'4'  that 
conventional  wide  field  of  view  CRT  displays 
would  require  24  channels  of  CIG  and  displays 
to  cover  a  hemisphere  with  two  arc -minutes  of 
resolution.  Alternatively,  the  FOHMD  design 
capitalizes  on  the  characteristic  rapid 
fall-off  of  visual  acuity  outside  of  the  fovea! 
region  (Figure  3)  by  providing  high  resolution 
only  in  the  central  FOV  surrounded  by  a  lower 
resolution  background  area.  This  transition 
from  high  resolution  to  low  resolution  roughly 
approximates  the  acuity  of  the  eye.  The  high 
resolution  area  is  optically  blended  into  the 
background  to  produce  a  "soft"  edge  between  the 
two  regions.  The  breadboard  FOHMD  has  a 
variable  25  or  40  degree  high  resolution  area 
for  research  purposes.  The  background  area  for 
each  eye  is  30  uegrees  wide,  providing  a  total 
instantaneous  FOY  of  135  degrees  horizontal  by 
60  degrees  vertical,  with  25°  of  overlap 
(Figure  4).  As  depicted  in  Figure  5,  the 
instantaneous  FOV  of  the  FOHMD  approximates  the 
view  normally  available  to  a  pilot  when  wearing 
a  standard  USAF  helmet. 


FIGURE  3  DISTRIBUTION  OF  VISUAL  ACUITY 
ACROSS  THE  RETINA  EXPRESSED 
IN  DEGREES  FROM  THE  FOVEA 

One  channel  of  high  resolution  and  one 
channel  of  low  resolution  imagery  are  computed 
for  each  eye,  resulting  in  a  total  of  four 
channels  of  imagery.  The  offset  between  the 
two  eyes  results  in  a  slightly  different 
picture  being  seen  by  each  eye.  Since  the 
appropriate  views  for  each  eye  are  computed, 
stereoscopic  depth  cues  are  available  with  the 
FOHMD  (they  are  not  available  with  most 
collimated  image  displays).  In  the  25  degree 
mode,  the  entire  high  resolution  area  for  each 
eye  is  completely  overlapped  with  the  imagery 
for  the  other  eye.  Since  normal  binocular 
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overlap  is  about  70  degrees^5),  one  of  the 
research  issues  to  be  addressed  with  this 
system  is  the  effect  on  visual  performance  of 
restricted  binocular  imagery.  A  closely 
related  research  issue  concerns  the  minimum 
acceptable  size  of  the  overlap  area. 

The  breadboard  FOHMD  uses  four  coherent 
fiber  optic  cables  made  by  A.  0.  Reichert 
Scientific  Instruments  to  transmit  imagery  to 
the  helmet.  Each  six-foot  long  cable  has  an 
8x10  millimeter  cross  section  and  is  covered 
with  a  highly  flexible  metal  hose.  Individual 
fibers  are  10  microns  in  diameter  and  are 
formed  in  5x5  multifiber  arrays.  A  chromatic 
multiplexing  image  enhancement  technique  has 
been  implemented  to  lessen  the  visual  effects 
of  broken  fibers  and  of  the  fiber  structure 
itself. >6)  This  technique  employs  one  prism 
to  spread  the  image  chromatically  on  the  input 
end  of  the  bundle  and  another  prism  to  recreate 
the  original  image  on  the  output  end. 
Improvements  in  the  fiber  optic  bundles  and  in 
the  image  enhancement  have  been  demonstrated 
and  will  be  included  in  the  follow-on  phase  of 
this  program. 

Farrand  Optical  Company  Inc.  developed  the 
FOHMD  optical  design.  A  beamsplitter  and 
miniature  Farrand  pancake  window™  are  used 
on  each  eyepiece  to  provide  wide  angle  infinity 
optics.  Although  there  is  the  usual  99 %  light 
loss  through  the  pancake  windows™,  the  FOHMD 
system  still  provides  an  Image  luminance  of  80 
foot  lamberts.  This  is  due  to  the  fact  that 
the  image  viewed  by  the  pancake  window™  is 
concentrated  in  an  area  of  less  than  one  square 
inch.  All  of  the  helmet  optics  in  the 
breadboard  system  are  currently  made  of  glass 
resulting  in  a  total  helmet/optics  weight  of 
approximately  nine  pounds.  Although  at  first 
this  may  seem  objectionable,  the  weight  in  the 
breadboard  system  has  been  successfully 
counterbalanced  and  is  not  a  major  problem. 
Future  production  systems  will  employ  lighter 
weight  optics  and  construction  techniques  to 
minimize  the  weight  and  inertia  of  the  system. 
The  FOHMD  system  has  a  large  fifteen  millimeter 
exit  pupil  and  provides  sufficient  eye  relief 
to  permit  wearing  glasses. 

The  Imagery  for  the  breadboard  FOUiD  is 
computed  by  two  Singer-Link  F-lll  Digital  Image 
Generators  (DIG  I).  Although  each  DIG  I  Is  a 
three  channel  system,  the  FOHMD  requires  only  a 
total  of  four  channels  of  imagery.  Each  DIG 
channel  generates  875  lines  by  1024  pixels  of 
color  Imagery  and  drives  a  General  Electric 
light  valve  projector  having  a  standard  3x4 
aspect  ratio.  There  are  8000  edges,  64  colors, 
and  64  intensities  available  for  detailed 
imagery.  Weather  effects  and  moving  models  are 
also  available.  The  FOWD  is  not  restricted  to 
any  particular  Image  generator  and  could  be 
used  in  conjunction  with  almost  any  image 
generation  source.  The  DIGs  are  currently 
being  used  to  demonstrate  the  compatibility  of 
the  FOHMD  with  a  commercially  available  color 
Image  generator. 


A  study  of  currently  available  helmet 
position  sensing  devices  was  included  as  part 
of  the  design  effort  for  the  FOHMD.  Results 
showed  that  commercial  helmet  sensor  systems 
were  inadequate  to  meet  the  demanding 
specifications  of  the  FOHMD  program,  which 
included  a  requirement  for  current  position 
data  at  a  minimum  rate  of  120  Hertz  in  all  six 
degrees  of  freedom.  To  permit  evaluation  of 
the  breadboard  FOHMD,  a  highly  effective 
mechanical  helmet  position  sensing  system  was 
fabricated  which  consists  of  a  two  bar,  three 
joint  linkage  and  measures  both  translational 
and  rotational  movement  (Figure  6).  A  more 
advanced  infrared  optical  sensing  system  is 
being  developed  for  the  follow-on  prototype 
FOHMD.  The  optical  sensor  will  use  two 
Hamamatsu  Cl 454  Position  Sensor  Heads  each  of 
which  is  capable  of  detecting  the  position  of 
an  infrared  light  emitting  diode  (LED)  in  two 
dimensions.  Two  sensors,  will  view  a  pattern  of 
six  LEDs  to  uniquely  determine  helmet 
position.  The  Hamamatsu  device  appears 
superior  to  other  conventional  noncontact 
position  detectors  because  of  its  accuracy  and 
speed.  This  optical  position  sensing  system 
will  be  able  to  run  at  iteration  rates  of  120 
hertz  and  still  maintain  its  accuracy. 


FIGURE  6.  MECHANICAL  HELMET  POSITION  SENSOR 

Although  the  FOHMD  seems  to  provide  the 
solution  to  the  brightness,  resolution,  and  FOV 
problems  inherent  in  conventional  flight 
simulators,  there  are  special  factors  which 
must  be  considered  when  using  a  head-coupled 
visual  simulator.  For  instance  visual  scene 
lag  becomes  a  critical  problem.  Conventional 
simulators  must  currently  only  generate  imagery 
fast  enough  to  keep  up  with  aircraft  movement. 
The  most  rapid  movement  of  a  modern  fighter 
aircraft  is  a  roll  with  typical  accelerations 
of  approximately  600  degrees/sec^  and  maximum 
values  ud  to  1200  degrees/sec*.  In  contrast, 
maximum  lead  acceleration  can  be  6,000 
degrees/ ;ec2.( Therefore,  head-coupled 
visual  simulators  must  be  much  more 
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responsive.  The  fastest  comnercially  available 
image  generators  can  generate  and  display  a 
visual  scene  in  three  fields  (one  field  equals 
16  2/3  msec).  If  throughput  for  the  position 
sensor  is  added  to  that  of  the  CIG,  then  the 
total  lag  time  approaches  four  to  five  fields. 
This  effect  will  create  pronounced  errors  in 
the  displayed  imagery.  Movement  of  300 
degrees/second  (typical  of  intense  visual 
search  patterns)  and  a  four  field  lag  will 
produce  a  twenty  degree  error  in  the  visual 
imagery.  To  counter  this  lag  problem,  AFHRL 
investigated  various  prediction  schemes  and 
determined  that  a  nonlinear  prediction 
algorithm  using  acceleration  values  can 
accurately  predict  future  head  position. 
Accelerometers  have  been  added  to  the  FOHMD 
which  have  effectively  minimized  perceptible 
visual  lags  caused  by  system  throughput  delay. 

The  FOHMD  system  also  employs  an  optical 
steering  technique  to  compensate  for  head 
motion.  During  head  movement,  a  mechanical 
steering  device  using  linear  motors  physically 
moves  the  fiber  optic  bundles  in  relation  to 
the  light  valve  projectors.  This  device  can 
correct  for  pitch  and  yaw  movements  of  plus  or 
minus  four  degrees.  Nonlinear  prediction  and 
optical  steering  appear  to  be  promising 
techniques  to  compensate  for  the  image  lags 
which  occur  in  a  head  slaved,  instantaneous 
field  of  view  system. 

The  advantages  of  higher  resolution,  higher 
brightness,  and  lower  CIG  channel  requirements 
which  are  available  with  head-coupled  displays 
can  be  even  further  exploited  through  the  use 
of  eye-slaved  displays.  A  head/eye  slaved 
system  would  permit  use  of  a  smaller  AOI, 
thereby  increasing  resolution.  Eye-slaving 
would  also  permit  adoption  of  a  variable  acuity 
approach  to  more  closely  approximate  the  acuity 
distribution  across  the  human  retina.  However, 
additional  eye  movement  data  must  be  obtained 
before  an  effective  eye-slaved  AOI  display 
system  can  be  developed. (8)  Part  of  the 
FOHMD  program  provides  for  a  parallel  research 
effort  to  investigate  issues  pertinent  to 
eye-slaved  systems.  (9)  An  off-line  eye-slaved 
projection  system  has  been  fabricated  to 
evaluate  an  eye-slaved  AO’  of  varying  sizes, 
within  a  lower  resolution  background. 

Minimally  tolerable  transport  delays  for  an 
eye-slaved  approach  will  also  be  investigated. 
The  FOHMD  has  been  designed  to  permit 
Incorporation  of  an  eye-slaved  approach,  if  and 
when  the  results  of  this  parallel  research 
effort  indicate  it  is  possible  to  do  so. 

Additional  human  factors  research  with  the 
FOHMD  system  will  investigate  broad  issues 
applicable  to  head-coupled  systems  in  general. 
For  Instance,  calibration-oriented  research 
will  be  conducted  to  determine  to  what  extent 
perceptual  anomalies  such  as  brightness/color 
differences,  binocular  rivalry,  and  image 
misalignment  are  detectable  and/or 
objectionable.  Other  areas  to  be  investigated 
include  Image  stability,  binocular  overlap, 
border  transition,  visual  fatigue  and  the 
tradeoffs  between  FOV  and  resolution. 


The  recently  delivered  breadboard  FOHMD  is 
intended  to  serve  as  a  concept  demonstration  to 
show  that  the  system  is  a  viable  approach  for 
achieving  high  fidelity  flight  simulation.  In 
the  follow-on  phase  the  system  will  be  expanded 
and  refined  to  produce  a  prototype  FOHMD.  The 
optical  tracker  will  be  incorporated  to  improve 
overall  position  sensing  performance  as  well  as 
improve  the  appearance  of  the  entire  system. 
Already  demonstrated  improvements  in  fiber 
optic  bundle  production  will  be  coupled  with 
additional  research  to  produce  smaller,  higher 
resolution  bundles.  A  total  of  only  two  fiber 
optic  bundles  will  be  used  on  the  prototype 
FOHMD  system.  This  will  eliminate  weight  and 
inertia  on  the  helmet  and  also  improve  outward 
appearance.  It  is  hoped  that  the  chromatic 
multiplexing  image  enhancement  technique  used 
in  the  breadboard  phase  can  be  replaced  by  a 
more  effective  dynamic  multiplexing  technique 
to  completely  eliminate  the  visible  fiber 
structure.  In  addition  to  the  display  itself, 
part  of  the  follow-on  effort  will  investigate 
the  special  requirements  which  a  head  coupled 
display  designed  for  both  air-to-air  and 
air-to-ground  simulation  may  impose  on 
instructor/operator  consoles. 

Throughout  the  follow-on  phase  critical 
technologies  pertinent  to  the  FOHMD  will  be 
constantly  monitored. (10)(11)  CRT,  projector, 
and  computer  image  generation  development  could 
significantly  affect  the  FOHMD  design.  One 
technology  which  may  be  applicable  is  that  of 
variable  resolution.  A  variable  resolution 
lens,  demonstrated  by  McDonnell  Aircraft 
Company (12)  can  selectively  distort  the  pixel 
spacing  of  an  image  to  create  a  higher  density 
of  pixels  in  the  center  of  the  field.  If  a 
small  size  variable  resolution  lens 
corresponding  to  the  acuity  of  the  eye  and 
adaptable  to  the  off  axis  requirements  of  the 
FOHMD  (higher  resolution  at  the  inner  edge  as 
opposed  to  the  center)  could  be  produced,  the 
required  number  of  image  generation  channels 
would  be  reduced  to  two,  and  one  arc -minute 
resolution  could  be  obtained.  Use  of  a 
variable  acuity  lens  would  require  some 
modifications  to  the  image  generation  source 
due  to  the  lack  of  appropriate  mapping 
functions  available  on  current  CIG  systems. 

THE  FUTURE? 

Technical  advances  to  date  have  made  visual 
flight  simulators  an  integral  part  of  most 
flight  training  programs.  The  extension  of 
visual  flight  simulation  into  the  combat  arena 
requires  further  advances,  but  promises  higher 
rewards.  The  demanding  tasks  of  combat 
engagements  place  correspondingly  demanding 
requirements  on  the  systems  that  simulate 
them.  Area  of  interest  simulation  systems  are 
being  seriously  pursued  by  both  the  military 
and  industry.  Successful  demonstrations  of 
systems  such  as  the  FOHMD  show  that  AOI 
displays  have  the  potential  to  provide  that 
elusively  affordable  combination  of  field  of 


view,  resolution,  brightness,  and  detail 
required  for  the  performance  of  complex  tasks. 
For  the  future,  it  may  not  be  within  the  realm 
of  fantasy  for  combat  aircrews  to  train  and 
rehearse  their  battles  using  full  fiel d-of-view 
helmet  mounted  displays! 


REFERENCES  USED 

1.  Hughes,  R. ,  Brooks,  R. ,  Graham,  D.,  Sheen, 
R. ,  and  Dickens,  T. ,  "Tactical  Ground  Attack: 
On  the  Transfer  of  Training  from  Flight 
Simulator  to  Operational  Red  Flag  Range 
Exercise"  in  Proceedings  of  the  Human  Factors 
Society  -  26th  Annual  Meeting  1952,  pp  596-600. 

2.  Cook,  P.  A.,  "Aerial  Combat  Simulation  in 
the  U.S.  Air  Force",  Astronautics  and 
Aeronautics,  September  1982,  pp  60-65. 

3.  LeMaster,  W.  D. ,  and  Longridge,  T.  M. ,  Area 

of  Interest/Field  of  View  Research  Using  ASRT, 

AFHRr/TO-78-Vr -  - 

4.  Spooner,  A.  M. ,  "he  Trend  Towards  Area  of 
Interest  in  Visual  Simulation  Technology"  in 


8.  Baldwin,  D. ,  Area  of  Interest  - 
Instantaneous  Field  of  View  Vision  Model"  in 
Proceedings  of  the  Image  Generation/Display 
Conference  II,  Scottsdale,  Arizona,  1C-12  June 
TUT  PP  4"81  -496. 

9.  Stober,  S. ,  Lippay,  A.,  McKinnon,  M. , 

Welch,  B. ,  Longridge,  T. ,  "A  Psychophysical 
Evaluation  of  an  Area  of  Interest  (AOI) 
Display."  Presented  at  the  1 9th  Annual 
Conference  on  Manual  Control ,  Massachusetts 
Institute  of  Technology,  23-25  May  1983. 

10.  Breglia,  D. ,  Spooner,  A.  M. ,  and  Lobb,  D. , 

"Helmet  Mounted  Laser  Projector"  in  Proceedings 
of  the  Image  Generation/Display  Conference  II, 
Scottsdale,  Arizona,  10-12  June- 1981, 
ppT41-25S. - 

11.  Breglia,  D.  R. ,  "Helmet  Mounted  Laser 
Projector"  in  Proceedings  of  the  Third 
Interservice/ImTustry  Training  Equipment 
Conference,  30  November  -  2  December  1981 , 

pp  8-1 8. 

12.  Fisher,  R.  W. ,  "A  Variable  Acuity  Display 

for  Simulator  Applications",  SID  Digest,  1982, 
pp  144-145.  '  . 


Proceedings  of  the  Fourth  Interservice/Industry 
Training  Equipment  Conference,  16-18  November 
1982,  pp  205-21 4. - 

5.  Tyler,  C. ,  "Sensory  Processing  of  Binocular 
Disparity"  in  Schor,  C.  M. ,  and  Ciuffreda, 

K.  J.,  (Eds)  Vergence  Eye  Movements,  Basic  and 
Clinical  Aspects,  Boston:  Butterworth,  1983.' 

6.  Siegmund,  W.  P. ,  Innis,  C.  J.,  Koester, 

C.  J.,  Gamble,  W.  J.,  "Fiber  Optics  Principles 
and  Applications  in  Medicine,"  Annals  of  the 
New  York  Academy  of  Sciences,  Volume  157, 
Article  T,'31Hareh  T969,  pp  47-59. 

7.  Lobb,  D. ,  Barber,  B.,  and  Murray,  P.M. , 
"American  Airlines,  Scanned  Laser  -  Final 
Report,"  prepared  for  Naval  Training  Equipment 
Center  under  Contract  No.  N-61 339-77-C-0001 . 


ABOUT  THE  AUTHOR 

Capt  Caroline  L.  Hanson  is  a  Scientific  Analyst 
at  the  Air  Force  Human  Resources  Laboratory, 
Williams  Air  Force  Base,  Arizona.  She  is 
currently  serving  as  the  Assistant  Program 
Manager  for  the  Combat  Mission  Trainer 
program.  Capt  Hanson  was  selected  as  the  Air 
Force  Systems  Command  Company  Grade  Officer  of 
the  Year  for  1982. 


AD-P003  483 


KM 


DIGITAL  CONTROL  LOADING  --  A  MICROPROCESSOR-BASED  APPROACH 

D.  Parkinson 

Link-Miles  Division,  The  Singer  Company 
Lancing,  Sussex,  England 

ABSTRACT 

This  paper  reports  on  a  multi-year  development  effort  to  provide  exact  simulation  of  air¬ 
craft  primary  control  systems  under  all  conditions  of  aircraft  control  and  operation  for  all 
regimes  of  flight  and  environment  conditions.  The  development  demonstrated  the  ability  to 
develop  realistic  models  and  provide  for  their  exact  solution  via  digital  computation  while 
integrated  with  a  highly  responsive  control  force  simulation  system.  Digital  quantization 
effects  are  eliminated  by  very  high  rates  of  computation  achieved  by  using  dedicated  micro¬ 
processors  within  the  control  loop,  resulting  in  no  degradation  of  control  "feel,"  smooth¬ 
ness,  or  response.  Further  improvements  in  long-term  stability,  calibration,  and  measurement 
are  also  achieved.  The  paper  discloses  the  results  of  various  comparative  analyses  between 
digital  and  analog,  for  various  force  and  position  servo  loops,  leading  to  the  development 
of  a  microprocessor-based  digital  control  loading  system.  Trace  comparisons  are  made  between 
the  final  breadboarded  system  versus  actual  aircraft  control  measurements  for  force/displace¬ 
ment  and  dynamic  stick  response  tests  to  demonstrate  the  fidelity  achieved  by  the  system. 


INTRODUCTION 

The  control  loading  system  of  a  flight  simu¬ 
lator  provides  one  of  the  prime  feedback  elements 
to  the  trainee.  The  fidelity  of  forces  at  the 
controls  is  very  important  in  the  training  role, 
and  while  quantitative  data  is  available  and  used 
for  design  of  such  systems,  it  is  an  area  where 
subjective  "feel"  also  provides  important  cri¬ 
teria.  Today's  advanced  level  of  simulation 
reached  in  flight  simulators  in  areas  such  as 
flight  dynamics,  visual  display  systems,  and 
general  system  simulation  requires  that  the  con¬ 
trol  loading  system  be  designed  to  the  same  level 
of  fidelity.  The  unique  problems  of  this  system 


present  a  challenge  to  the  design  engineer  who 
has  usually  had  to  make  substantial  compromises 
to  achieve  an  acceptable  solution. 

The  "feel"  of  the  controls  experienced  by  the 
pilot  results  from  a  number  of  different  forces. 
These  are  character!  zed  as  spring,  breakout, 
damping.  Coulomb  friction,  etc.,  some  of  which 
are  a  function  of  velocity.  Tne  complex  non¬ 
linear  functions  of  the  above,  together  with 
usual  design  parameters  of  low  cost,  low  mainte¬ 
nance,  and  high  reliability,  form  the  basis  of 
the  problem.  The  principal  components  of  a 
control  loading  system  are  shown  in  Figure  1. 
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The  traditional  solution  is  to  employ  a  spe¬ 
cial-purpose  analogue  computer  to  solve  these 
complex  functions  and  second-order  differential 
equations  with  sufficient  frequency  response  to 
achieve  the  necessary  smooth  response.  This 
type  of  system  provides  adequate  performance  but 
has  inherent  limitations.  First,  there  is  the 
long-term  drift  associated  with  any  analogue  com¬ 
putation  which,  if  not  corrected,  affects  the 
calibration  of  the  system.  The  inability  to  pro¬ 
vide  adequate  self-check  or  performance  monitor¬ 
ing  increases  the  problem  associated  with  lack 
Lf  general  stability.  The  calibration  of  non¬ 
linear  functions  against  associated  aircraft 
data  is  also  a  time-consuming  task  with  little 
possibility  of  applying  automatic  techniques  and 
other  aids  within  an  analogue  design. 

Also,  the  system  design  for  each  type  of 
aircraft  is  unique  and  consequently  leads  to  a 
schedule  problem  and  high  recurring  design  costs. 
Each  circuit  card  contains  a  part  of  the  analogue 
computation  and,  while  the  basic  design  is  common 
for  most  aircraft  types,  the  non-linear  func¬ 
tions,  time  constants,  and  other  parameters  asso¬ 
ciated  with  aircraft  performance  have  to  be 
designed  into  the  resulting  unique  circuit  card. 
The  use  of  variable  potentiometers  offsets  some 
of  these  problems,  but  this  in  turn  leads  to 
complicated  calibration  methods.  The  impact  of 
this  problem  is  exaggerated  further  if  data 
associated  with  the  aircraft  being  simulated  is 
not  available  until  late  into  the  contract. 

The  recent  revisions  to  the  U.b.  Federal 
Aviation  Administration  regulations  for  the 
evaluation  and  approval  of  flight  simulators 
have  also  complicated  the  design  task.  Under 
the  new  rules  it  is  no  longer  sufficient  to 
compare  the  simulator  characteristics  with  the 
aircraft  manufacturer's  engineering  data  for  the 
control  system.  The  simulator  now  has  to  be  com¬ 
pared  directly  with  measurements  made  on  one  of 
the  customer's  aircraft.  As  the  differences  be¬ 
tween  individual  aircraft  of  a  particular  type, 
together  with  the  tolerances  on  the  measurement 
procedure,  can  easily  exceed  the  tolerances  al¬ 
lowed  on  the  simulator,  this  can  result  in  the 
necessity  to  modify  the  mathematical  model  for 
each  application.  In  addition  to  this,  the  air¬ 
craft  measurements  are  not  always  available 
before  the  simulator  design  is  due  to  be  com¬ 
pleted.  These  two  factors  now  make  it  essential 
that  the  mathematical  model  be  easily  modifiable 
up  to  the  time  of  simulator  acceptance. 

The  performance  of  minicomputers  generally 
used  for  flight  simulators  is  obviously  powerful 
enough  to  achieve  the  required  iteration  rates, 
but  they  are  too  expensive  to  be  dedicated  to 
the  control  loading  system.  It  is  the  advent  of 
powerful  microprocessors  which  can  offer  the 
price/performance  to  apply  to  such  systems. 
Therefore,  it  was  decided  from  the  outset  that 
microprocessors  would  be  used  in  the  final 
design. 

OBJECTIVES 

The  objective  of  this  development  program 
was  to  produce  a  microprocessor-based  digital 
control  loading  system  which  would  interface 
with  existing  simulator  configurations.  The 
final  design,  however,  also  had  to  be  compatible 


with  possible  future  simulator  configurations 
which  may  not  be  dependent  on  a  central  com¬ 
puting  complex. 

The  hardware  had  to  be  configured  in  such  a 
way  that  it  would  be  cost-effective  when  applied 
to  a  large  range  of  simulator  types.  The  antici 
pated  applications  range  from  helicopters  to 
wide-bodied  commercial  aircraft.  The  use  of 
powered  actuators  to  simulate  aircraft  control 
systems  is  not  limited  to  the  primary  flying 
controls  (elevator,  aileron,  and  rudder).  This 
technique  is  also  useful  in  the  simulation  of 
some  secondary  flight  controls  such  as  speed- 
brake  handles  and  toe  brake  pedals.  In  these 
cases,  the  servo  actuator  may  well  be  a  simple 
positional  device  with  a  much  lower  output  than 
is  required  for  a  primary  control  system.  It 
was  therefore  a  requirement  that  the  computing 
elements  should  be  capable  of  controlling  a 
number  of  different  servomechanisms. 

In  order  to  accommodate  the  large  range  of 
simulators,  it  was  also  a  requirement  that  the 
number  of  computing  channels  could  be  expanded 
in  a  modular  fashion  from  a  minimum  of  two  up  to 
a  maximum  of  fourteen. 

DESIGN  CONCEPTS 

The  simulation  of  the  correct  feel  of  a  con¬ 
trol  system  can  be  conveniently  broken  down  into 
two  parts.  First,  there  is  the  inner  loop  which 
comprises  the  actuator  mechanically  connected  to 
the  pilot's  control,  together  with  the  servo  sys 
tern  necessary  to  drive  it.  The  outer  loop  con¬ 
tains  the  computing  elements  necessary  to  make 
the  actuator  reproduce  the  particular  feel 
characteristics  of  the  aircraft  system. 

In  the  case  of  a  primary  flight  control 
system  the  inner  loop  will  contain  a  hydraulic 
actuator  and  a  force  loop  servo  system,  but  in 
other  applications  it  could  well  be  a  hydraulic 
position  servo  or  even  an  electric  torque  motor. 
Whatever  inner  loop  is  chosen,  the  outer  loop 
can  use  the  same  microprocessor  board  and  digi¬ 
tal  -to-analogue  conversion  equipment.  The  use 
of  an  independent  microprocessor  in  each  channel 
allows  the  computer  cycling  time  to  be  adjusted 
to  suit  each  application. 

It  is  also  important  that  the  interface 
between  the  microprocessors  and  the  Host  compu¬ 
ter  be  handled  in  a  flexible  manner  so  that  it 
can  easily  be  adapted  for  use  with  any  simulator 
computing  system. 

HARDWARE 

Inner  Loop 

The  most  critical  control  loading  applica¬ 
tions  on  a  flight  simulator  are  the  three  pri¬ 
mary  flight  controls  plus  the  nosewheel  steering 
system.  For  these  systems  the  inner  loop  will 
normally  consist  of  a  hydrostatic  hydraulic  actu 
ator  coupled  to  the  pilot's  control  through  a 
force  sensing  load  cell.  The  position  of  the 
actuator  is  measured  with  a  linear  position 
transducer  (LVDT)  ad  an  analogue,  force-feed- 
back  servo  system  provides  the  control  signal  to 
the  servo  valve.  This  arrangement  has  been  used 
on  control-loading  systems  for  some  years  and 


has  been  shown  to  produce  a  sensitive,  high-band¬ 
width,  but  stable  system. 

In  addition  to  controlling  the  hydraulic 
actuator,  the  inner  loop  circuit  must  also  fail 
safe  to  prevent  any  malfunction  in  the  compo¬ 
nents  causing  damage  to  the  simulator  or  harm  to 
pilot.  This  is  achieved  by  monitoring  power  sup¬ 
plies,  actuator  force,  actuator  velocity,  etc., 
and  deactivating  a  fast-operat i ng  hydraulic 
safety  valve  when  any  of  the  parameters  exceed 
predefined  limits. 

Outer  Loop 

The  digital  outer  loop  for  each  channel  one 
CPU  card,  and  one  I/O  card  as  shown  in  Figure  2. 


The  CPU  card  employs  the  Intel  8  MHz  8086 
processor  with  4  K  bytes  of  RAM  and  32  K  bytes 
of  EPROM.  Two  DCL  channels  may  be  closely 
coupled  and  run  in  synchronism  through  the 
card's  FIFO  interface,  giving  communication 
between  the  two  at  512  Hz.  This  facility  would 
be  used  in  a  simulator  for  an  aircraft  which  has 
dual  control  runs  from  sticks  to  control  sur¬ 
faces.  Normally,  the  two  controls  would  be  used 
to  move  as  one,  but,  in  the  event  of  a  jam,  the 
controls  may  be  split  and  would  then  have  to 
operate  independently  of  each  other. 

The  CPU  has  its  real-world  interface  on  the 
associated  I/O  card.  This  comprises  a  16-chan¬ 
nel  multiplexed  analogue-to-digital  converter- 
plus  four  channels  of  digital-to-analogue  con¬ 
version.  Although  the  A-to-D  has  16  input 
channels,  only  eight  are  for  conversions  from 
the  outside  world.  The  remainder  are  used  for 


wrap-around  tests  of  the  analogue  outpufs  and 
power  supply  level  checks. 

For  each  simulator's  control  loading  subsys¬ 
tem,  an  interface  is  required  between  the  20  Hz 
or  30  Hz  Host  tasks  and  OCL's  specialized  512  Hz 
routines.  For  a  typical  SEL  32/77  Host  Computer 
the  High  Speed  Data  (HSD)  and  compatible  inter¬ 
face  card  is  used.  This  contains  a  1  K-word 
buffer  RAM  which  interfaces  to  tne  final  card  in 
the  system,  the  crosstalk  CPU  { CPU X ) . 


The  main  function  of  CPUX,  on  interrupt  from 
the  Host,  is  to  transfer  data  between  the  buffer 
RAM  on  the  HSD  interface  card  and  the  double- 
buffered  RAM's  on  each  channel's  I/O  card.  On 
completion  of  this  task,  CfJX  flags  the  double 
buffered  RAM's  which,  then,  in  synchronism  with 
each  channel's  real-time  clock,  swap  the  RAM 
areas  over.  Other  functions  of  the  card  include 
the  updating  of  a  data  entry  panel  and  control 
of  a  multi-channel  RS232  link  which  may  be  real¬ 
located  to  any  of  the  CPU's  in  the  system  en¬ 
tirely  under  software  control.  When  a  VDU  is 
not  available,  the  data  entry  panel  provides  a 
single  location  look-and-enter  facility  to  any 
of  the  channels.  The  card  again  uses  the  8086 
with  4  K  RAM  and  16  K  EPROM  plus  standard  LSI  to 
interface  with  the  data  entry  panel  '-omponents. 

The  iteration  rate  of  512  Hz  was  chosen  to 
produce  the  smooth  response  required.  It  can 
easily  be  shown  that  such  computational  rates 
are  required  to  achieve  bandwidths  of  around  100 
Hz.  This  was  supported  by  qualitative  assess¬ 
ments;  iterations  of  256  Hz  produced  a  detect¬ 
able  noise  level,  while  performance  at  1  ,024  Hz, 
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made  possible  by  coding  certain  routines  in 
assembler  rather  than  PLM,  did  not  give  an  im¬ 
provement  over  512  Hz.  All  these  tests  used  a 
complete  math  model  for  a  primary  747  control 
channel.  Each  channel  can  be  assigned  an  unique 
iteration  rate,  and  the  real-time  executive  and 
debug  in  each  CPU  and  I/O  can  support  multiple 
programs,  say  for  small  secondary  control 
functions. 


SOFTWARE 

One  of  the  advantages  of  the  digital  ap¬ 
proach  is  that  it  provides  a  cost-effective 
method  of  implementing  a  detailed  mathematical 
model  of  the  aircraft  system.  A  typical  air¬ 
craft  primary  flight  control  system  contains  a 
number  of  distinct  elements.  On  the  flight  deck 
there  is  the  pilot's  control  column,  torque 
tube,  and  drive  mechanism  to  the  forward  caole 
drum.  These  components  contribute  mass,  out-of- 
balance  forces,  and  friction  to  the  overall  feel 
of  the  system.  The  next  item  is  the  cable  run 
connecting  the  forward  cable  drum  to  the  com¬ 
ponents  in  the  rear  of  the  aircraft.  The  pri¬ 
mary  contribution  of  this  is  a  spring  effect 
plus  friction  and  viscous  damping.  Situated  at 
the  rear  of  the  aircraft  is  the  artificial  feel 
system  which  usually  comprises  one  or  more 
springs,  possibly  with  a  means  of  adjusting  the 
mechanical  advantage  so  that  the  spring  rate,  as 
seen  by  the  pilot,  can  be  varied  with  the  air¬ 
craft  speed.  These  items  largely  determine  the 
static  force/displacement  character! sties  expe¬ 
rienced  by  the  pilot  but  they  also  contribute  to 
the  mass,  friction,  and  viscous  damping  in  the 
system.  The  ai  rcraf  t-powered  surface  actuators 
are  situated  in  this  area  and  these  also  contri¬ 
bute  to  the  feel  of  the  system  as  they  generally 
impose  a  velocity  limit  on  components  at  the 
rear  of  the  aircraft  as  a  function  of  the  flow 
available  from  the  aircraft  hydraulic  supplies. 
The  final  component  which  needs  to  be  considered 
is  the  autopilot  actuator,  as  this  usually  has 
the  ability  to  apply  forces  to  the  aircraft 
actuator  input  mechanism. 

In  addition  to  simulating  the  components  of 
the  aircraft  system,  the  mathematical  model  pro¬ 
grammed  into  the  microprocessor  must  also  take 
account  of  any  non-linearities  which  exist  in 
the  simulator  installation.  These  non-linear¬ 
ities,  which  usually  occur  as  a  result  of  using 
aircraft  parts  in  the  flight  deck  area,  affect 
the  relationship  between  pilot  force  and  the 
force  measured  at  the  load  cell  and  the  control 
position  and  the  position  measured  by  the  LVUT. 

Once  the  mathematical  model  for  a  particular 
system  has  been  developed,  it  is  programmed  in  a 
high-level  language.  During  development,  the 
software  is  downloaded  from  a  Microprocessor 
Development  System  to  RAM  within  the  DCL  system 
and  then  programmed  in  EPROM  when  verified.  The 
design  of  the  software, due  to  individual  proces¬ 
sors  for  each  channel , he' ps  in  the  task  and  also 
decreases  the  life  cycle  cost  of  the  total 
software. 

The  simulation  module  is  run  effectively  as 
an  interrupt  task  every  1.95  ms.  Depending  on 
the  complexity  of  the  task,  this  generally  takes 
about  1  to  1.3  ms  and,  on  completion,  the  CPU 


returns  to  its  background  program.  This  back¬ 
ground  routine  consists,  firstly,  of  updating 
information  on  the  debug  page,  and  secondly,  of 
running  diagnostic  tests  and  reporting  back  the 
status  of  the  channel  to  the  Host  in  real  time. 

In  addition  to  these  tests,  the  channel  CPU's, 
at  power  up,  pass  through  "Morning  Readiness" 
checks  which  exercise  the  I/O  components,  per¬ 
form  RAM  and  EPROM  tests  and  ensure  that  the 
system  is  in  a  fit  state  to  operate  control 
1  oadi  ng. 

Any  fault  condition  flags  are  passed  back  to 
CPUX  and  thence  to  the  Host.  Thus  faults  can 
easily  be  traced  from  system  level  to  channel 
level  to  board  level  and,  within  certain  con¬ 
straints,  to  component  level  from  the  simulator's 
main  computer. 

Channels  passing  Morning  Readiness  checks 
automatically  proceed  with  their  simulation 
tasks,  requiring  only  the  manual  'hydraulics  on' 
switch  to  be  pressed  before  full  simulation 
commences . 

BENEFITS  OF  DIGITAL  CONTROL  LOADING 

The  digital  approach  to  control  loading 
systems  has  eliminated  the  need  for  unique 
analogue  circuit  cards  in  the  simulator  system. 
This,  coupled  with  the  inherent  long-term  sta¬ 
bility  of  a  digital  system,  should  yield  a  signi¬ 
ficant  reduction  in  the  simulator  maintenance 
effort.  The  absence  of  unique  hardware  is  also 
important  to  the  simulator  manufacturer,  as  it 
means  that  the  various  mathematical  models  re¬ 
quired  can  oe  verified  and  evaluated  on  a  stand¬ 
ard  test  tig  before  the  simulator  construction 
is  complete. 

With  the  digital  approach,  the  mathematical 
model  is  much  more  easily  modified  to  account 
for  aircraft  characteri  st  i  cs  which  were  not  iden¬ 
tified  during  tne  initial  analysis.  This  is 
important  as  sometimes  these  characteristics 
only  become  apparent  when  a  pilot  who  is  expe¬ 
rienced  on  the  particular  aircraft  type  has  the 
opportunity  to  assess  the  simulator.  Tms  added 
flexibility  results  in  improvements  in  the  stand¬ 
ard  of  simulation.  Inis  has  been  demonstrated 
by  programming  our  test  facility  to  represent 
the  elevator  channel  of  a  Boeing  74/  aircraft. 

The  degree  of  agreement  achieved  between  this 
facility  and  a  of  measurements  made  on  a 
particular  aircraft  was  excellent,  with  typical 
results  shown  in  figure  3.  Tne  adjustments  nor¬ 
mally  required  to  tune  a  control  system  perform¬ 
ance  to  'li.itcn  a  set  of  measurements  made  on  a 
specific  aircraft  are  provided  from  the  main 
simulator  computer.  It  is  anticipated  that  some 
dO  parameters  per  channel  will  be  defined  within 
the  main  computer  data  base.  These  parameters 
will  allow  the  rapid  and  accurate  adjustment  of 
terms  like  friction  levels,  rate  dampings,  break¬ 
out  forces,  etc. 

Digital  control  provides  a  very  powerful 
means  of  imp  lener  t  i  ng  self-test  i  id  diagnostic 
features.  In  our  standard  s'Hul.i  or  package,  we 
include  a  lest  Guidt  Driver  facility  to  set  up 
the  initial  conditions  and  automat i cal ly  run  the 
required  force /J  i  sp  1  acement  and  dynamic  response 
tests.  Die  results  of  these  tests  may  be 
recorded  directly  by  connecting  the  output  of 
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Figure  3  DYNAMIC  RESPONSE  CHECK  -  8-747 
ELEVATOR 


the  control  loading  unit  force  and  position 
transducers  to  a  suitable  chart  recorder.  Alter¬ 
natively,  the  same  results  may  be  displayed  as  a 
graphical  plot  on  the  instructor's  station  visual 
display  unit,  from  which  a  permanent  copy  can  be 
made  by  means  of  a  line  printer. 

The  same  instructor's  VDU  can  be  used  to  dis¬ 
play  warning  messages  should  a  malfunction  be 
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In  the  event  of  the  safety  circuit  for  a  par¬ 
ticular  control  loading  channel  tripping,  then 
information  on  the  status  of  that  channel  will 
be  recorded  at  the  instant  of  the  failure  and 
will  be  available  for  subsequent  display.  The 
recorded  information  will  include  power  supply 
voltages,  anal ogue-to-di gi tal  and  digital-to- 
analogue  converter  status,  control  loading 
actuator  force,  velocity,  velocity  error,  and 
position  error. 
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ABSTRACT 


Very  High  Speed  Integrated  Circuits  (VHSIC)  is  a  new  technology  which 
promises  to  have  a  major  impact  on  the  training  and  training  device  community. 
As  DoD  and  industry,  in  a  joint  effort,  began  to  pursue  this  technology  in 
1980,  it  quickly  became  obvious  that  VHSIC,  if  successful,  would  result  in 
more  than  just  an  evolutionary  change  in  microelectronics  --  it  had  the 
potential  to  revolutionize  the  way  in  which  we  design,  build,  and  use 
electronic  devices.'  At  this  point  in  1983  the  performance  predictions  for  the 
VHSIC  technology  are  very  close  to  being  achieved.  Not  only  will  we  have 
available  to  us  significant  increases  in  processing  throughput,  but  the  VHSIC 
chips  will  be  smaller,  lighter,  require  less  power,  and  be  more  reliable  than 
their  predecessors.  Cost  savings  are  also  predicted.  As  these  advantages 
came  close  to  reality  in  1982,  the  Naval  Training  Equipment  Center  recognized 
a  tremendous  potential  in  the  new  chips  to  improve  the  future  training  devices 
and  solve  some  problems  being  presented  by  the  limitations  of  current 
technology.  Therefore,  a  study  contract  was  let  to  Honeywell  (one  of  the  six 
DoD  VHSIC  contractors)  to  investigate  the  impact  of  VHSIC  on  training  and 
training  devices.  This  paper  will  discuss  the  results  of  that  study  and 
indicate  the  future  direction  in  which  the  VHSIC  technology  will  drive  the 


training  community. 

A 

INTRODUCTION 

The  DoD  VHSIC  program  was  established 
to  provide  focus  and  resources  to  overcome 
the  limitations  of  silicon  IC  technology, 
and  has  far  reaching  implications  relative 
to  the  security  of  this  nation.  Not  only 
is  VHSIC  the  next  logical  step  to  maintain 
technological  leadership  in  micro¬ 
electronics,  but  its  application  to 
military  hardware  will  provide  a  distinct 
advantage  in  fielding  more  sophisticated 
military  systems.  However,  as  one  begins 
to  understand  the  tremendous  improvements 
allowed  by  the  VHSIC,  it  becomes  obvious 
that  our  new  weapons  systems  are  not  the 
only  potential  benefactors  of  the  new 
technology.  Indeed,  the  VHSIC  advantages 
can  be  applied  to  almost  any  electronic 
device  and  have  the  potential  to  make 
significant  impacts  throughout  both 
military  and  civilian  arenas.  Its  not 
just  a  matter  of  accomplishing  the  same 
electronic  function  in  a  more  efficient 
manner.  The  VHSIC  will  allow  us  to  push 
back  the  existing  electronic  design 
boundaries  and  accomplish  new  roles  which 
were  heretofore  beyond  the  limits  of  our 
technology.  We  can,  therefore,  expect  to 
see  impacts  on  how  we  operate,  maintain, 
and  use  the  new  electronic  devices  made 
possible  by  the  VHSIC  development. 

Since  the  Naval  Training  Equipment 
Center  is  charged  with  responsibility  to 


develop,  procure,  and  support  Navy 
training  systems,  the  DoD  plan  to  push  the 
VHSIC  technology  is  viewed  with  both 
excitement  and  apprehension.  After  all, 
it  is  easy  to  envision  the  VHSIC  as  not 
only  a  better  way  of  building  the 
traditional  training  device,  but  also  a 
technology  that  will  facilitate  and  even 
demand  new  approaches  to  training.  With 
these  thoughts  in  mind,  it  became 
necessary  to  do  some  research  and  analysis 
into  the  VHSIC  impact  on  training  in  order 
that  a  future  course  of  action  may  be 
charted  to  allow  preparation  for  a  full 
exploitation  of  the  new  VHSIC  technology. 
That  was  the  purpose  of  the  Honeywell 
study,  the  results  of  which  are  reported 
herein. 

In  order  to  make  this  paper 
understandable  to  those  who  may  not  have 
carefully  followed  the  VHSIC  development, 
we  have  included  a  synopsis  of  the  DoD 
VHSIC  program.  The  goals  and  approach  of 
the  study  will  then  be  described,  followed 
by  the  results.  There  has  been  an  attempt 
to  chart  a  direction  for  VHSIC  insertion 
into  training  devices  which  involves  the 
development  of  a  Training  Chip  Set  (TCS) . 
Plans  for  the  TCS  include  the  objective  to 
make  the  chips  available  to  all  training 
systems  designers  without  providing  any 
competitor  a  major  advantage  in  the 
marketplace. 
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Overview  VHSIC  Program 

The  DoD's  VHSIC  program  was  divided 
into  several  phases  over  a  six-year 
period,  beginning  in  March  1980. 

During  Phase  0  of  the  program,  March 
to  November  1980,  nine  contractors  were 
selected  to  develop  concepts  and 
brassboard  chip  projects  that  would  best 
meet  the  long-term  objectives  of 
developing  new  microelectronic  technology 
and  devices  that  ate  geared  to  the 
specific  constraints  of  defense  systems. 
As  a  result  of  the  Phase  0  study,  six 
contractors  have  been  awarded  Phase  1 
contracts  to  take  their  concepts  to 
reality  by  mid-1984.  A  Phase  2  program 
was  awarded  in  August  1981  with  the 
objectives  of  (1)  yield  enhancement,  (2) 
technology  insertion,  (3)  sub-micron 
technology  development,  and  (4)  developing 
integrated  design  automation  systems.  In 
concert  with  the  Phase  1  and  Phase  2 
efforts.  Phase  3  of  the  program  (1980- 
1986)  provides  the  supporting  research 
effort  in  the  form  of  a  large  number  of 
small  contracts  (60  contractors)  to  enlist 
the  innovative  research  and  development 
efforts  of  the  much  broader  community  of 
researchers  in  industry,  universities  and 
research  institutions.  A  summary  of  the 
VHSIC  program  schedule  is  shown  in  Figure 
1. 


The  objective  of  the  VHSIC  Phase  1 
program  is  three-fold.  The  first  is  to 
design,  fabricate,  and  test 
1.25  micron  geometry  integrated  circuits 
(IC's),  with  a  minimum  functional  through¬ 
put  rate  (FTR)  of  5  x  10"  gate  -  Hertz 
per  square  centimeter.  The  FTR  is  a 
product  of  gate  density  and  speed.  The 
second  objective  is  to  demonstrate  a  pilot 
line  capability  to  produce  VHSIC  chips. 
The  third  objective  is  to  deliver  brass- 
board  chips  to  demonstrate  VHSIC  perfor¬ 
mance.  insert  VHSIC  into  other  military 
applications. 

The  VHSIC  Phase  2  program  procurement 
is  currently  underway.  The  original  plan 
was  to  extend  the  limits  of  the  1.25 
micron  technology  to  sub-micron  feature 
sizes.  However,  the  experience  gained 
from  the  VHSIC  Phase  1  program  thus  far 
has  shown  that  the  1.25  micron  technology 
will  yield  sufficient  benefits  to  numerous 
military  system  applications  to  support 
continued  development. 

The  current  emphasis  for  Phase  2 
seems  to  have  three  major  objectives.  The 
first  one  is  to  facilitate  VHSIC 
technology  transfer.  This  involves 
efforts  to  encourage  VHSIC  Insertion  into 
various  weapon  systems.  Second,  achieve 
IC  pilot  line  certification  and  to  reduce 
chip  costs.  The  third  objective  is  to 
develop  the  sub-micron  process  technology. 
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Figure  1.  VHSIC  Program  Schedule 
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Currently,  the  overall  status  of  the  technology  widely  applicable  to  the  DoD 

VHSIC  Phase  1  program  can  be  summarized  as  community.  These  issues  can  be  grouped 

follows:  into  three  main  areas: 

o  Design  verification  is  in  progress  o  Interoperability 

o  Chip  design  is  in  final  revision  o  Support  Environments 

o  Device  and  process  characteriza-  o  Procurement  Options 

tion  is  in  progress 

Each  of  these  issues  has  a 

o  Brassboard  design  is  underway  significant  impact  on  the  user  of  VHSIC 

technology.  Without  chip  interoperability 
A  summary  of  the  characteristics  of  among  the  six  contractors,  the  design  of 

the  chip  sets  and  brassboards  that  are  any  system  may  be  constrained  to  the  use 

currently  being  developed  for  VHSIC  Phase  of  chips  from  one  manufacturer.  In 

1  is  shown  in  Table  1.  addition,  VHSIC  chips  will  be  more  easily 

accepted  if  a  user-friendly  software 

VHSIC  Technology  Issues  support  environment  is  available. 

Finally,  unless  the  technology  can  be  made 
As  the  VHSIC  Phase  1  program  proceeds  readily  available  in  a  variety  of  manners 

along  with  the  chip  development  efforts,  (i.e.,  transferable),  potential  users, 

both  the  VHSIC  contractors  as  well  as  the  other  than  the  original  may  be  faced  with 

potential  users  are  beginning  to  problems  that  could  make  the  use  of  VHSIC 
investigate  and  address  the  various  issues  unattractive, 
that  must  be  resolved  to  make  VHSIC 


Table  1.  Summary  of  VHSIC  Phase  1  Contractor  Approaches  (Excerpt  from 
IEEE  Spectrum,  December  1982) 


Contractor 

(Service) 

Technology 

BraaBboard 

Design  Approach 

Chip  Set 

Special  Features 

Honeywell 
(Air  Force) 

Bipolar  ILS*, 

CML# 

Electro-optical 
signal  processor 

Custom  chip  based 
macrocell  library 

Parallel  program¬ 
mable  pipeline 
Controller 

Radiation  hardness 
Responsive  generic 
architecture 

Hughes 

(Army) 

CMOS  on  SOS 

Anti  jam 
communication# 

Standard  and  custom 
reconf igurable  chips 

Digital  correlator 
Algebraic  encoder/ 
decoder 

Spread-spectrum 

subsystem 

Radiation  hardness 
Electron  beam  direct- 
write  lithography 

Highly  apecalixed 
chips 

IM 

(Navy) 

NMOS 

Acoustic  aignal 
processor 

Raster  image  with 
macrocell  library 

Complex  multiplier/ 
accumulator 

Software  strength 

Design  approach 

Texas 

Instruments 

Bipolar  STL## 
NHOS 

Multi-mode  fire- 
and-forget  missile 

Programmble  chip 
set 

Data  processor 

Array  controller 
and  sequencer 

Vector  addrese 
generator 

Static  RAM 

Multi-path  switch 
Device  Interface 
unit 

General  buffer  unit 

Operational  fabrication 
facility 

Design  utility  system 

TRW 

(Havy) 

Bipolar-3D** 

TTL,  CMOS 

Electronic-warfare 
signal  processor 

Standard  chip  aet 

Content  addressable 
memory 

Window  addressable 
memory 

Registered  arith¬ 
metic  logic  unit 
Address  generator 
Matrix  switch 

15-bit  muliplier/ 
accumulator 
Micro-controller 
Four-port  memory 

Innovative  memory  chips 
Versa tile  chip  set 

! 

i 

westing house 
(Air  Force) 

Bulk  CHOS 

Advanced  tscticsl 
radar  processor 

Standard  chip  set 
unit 

Pipeline  arithmetic 
unit 

Extended  arithmetic 
unit 

Controller 

Gate  array 

Static  RAH 

Mutipliar 

Highest  speeds 

*  Integrated  Schottky  logic,  ^Current  mode  logic,  MSchottky  transistor  logic,  **Triple  Diffusion 
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VHSIC  Interoperability  Issues .  The 
six  VHSIC  Phase  1  contractors  are  all 
working  very  hard  to  develop  and  fabricate 
their  respective  chip  sets  and  brass- 
boards.  Each  is  developing  one  of  the 
competitive  IC  technologies  —  NMOS,  bulk 
CMOS,  CMOS  on  SOS,  and  bipolar  —  to  the 
design  and  fabrication  of  chips.  Due  to 
the  nature  of  the  VHSIC  program,  each 
contractor  is  working  independently. 
Outside  of  initial  program  objectives, 
little  consideration  has  been  given  to  the 
issue  of  interoperability;  i.e.,  how  VHSIC 
chips  of  different  manufactures  can  be 
used  in  the  same  system.  The  need  for 
some  form  of  standardization  among  the 
VHSIC  chips  is  beginning  to  be  recognized 
and  different  committees  and  action  groups 
have  been  set  up  to  look  into  these  issues 
and  to  recommend  possible  solutions.  In 
particular,  three  topics  are  currently 
being  pursued:  bussing,  power  supply  volt¬ 
ages,  and  packaging.  Committees  have  been 
set  up  to  provide  guidance  and  standardi¬ 
zation  to  the  individual  developers. 

To  resolve  these  questions,  a  VHSIC 
interconnect  standards  committee  (V-BUS) 
has  been  formed,  with  participants  from 
all  six  VHSIC  contractors  and  the  user 
community. 

VHSIC  Support  Equipment.  The  VHSIC 
Support  Environment  needs  can  be  divided 
into  two  major  areas:  support  of  software 
tools  and  support  of  Computer  Aided  Design 
tools. 

Software  Support.  The  software 
support  tools  development  effort  is 
directed  at  two  levels: 

o  High  Level  -  Ada  programming 
support 

o  Low  Level  -  Microcode  compiler 

DoD  has  identified  Ada  as  the  stan¬ 
dard  high  order  language  for  use  in  the 
future.  All  the  VHSIC  chips  have  been 
designed  to  be  compatible  with  this  re¬ 
quirement.  Two  programs  are  currently  in 
progress  to  define  and  develop  the  Minimal 
Ada  Programming  Support  Environment 
(MAPSE).  The  first  one,  called  Ada 
Language  System  (ALS) ,  is  let  out  of  the 
Army  (CECOM)  to  Softech.  The  effort  is 
hosted  on  a  VAX-700/VMS  and  is  scheduled 
to  be  completed  by  January  1984.  The 
second  effort,  called  Ada  Integrated 
Environment  (AIE) ,  is  let  out  of  Air  Force 
(RADC)  to  Intermetric.  The  system  is 
hosted  on  IBM  370/VM  and  is  due  at  the  end 
of  1984. 

Table  2  shows  the  tools  for  use  in 
Ada  Programming  as  a  result  of  the  two 
programs. 

While  these  two  efforts  are  going  on, 
there  are  already  available  in  the 
commercial  market  less  sophisticated 
compilers  for  subsets  of  Ada.  These  tools 


can  be  very  useful  for  learning  Ada  and 
for  training  Ada  programmers. 

Table  2.  Ada  Support  Tools 

KAPSE  (Kernel  Ada  Programming  Support 

Environment) 

Virtual  Support  Environment 
I/O  Support 
Data  Base  Support 
Operating  System  Support 

MAPSE  (Minimal  Ada  Programming 

Support  Environment) 

Text  Editor 

Prettyprinter 

Translator 

Linkers 

Loaders 

Analysis  Tool 

Terminal  Interface 

File  Administrator 

Command  Interpreter 

Configuration  Manager 

For  VHSIC  chips  to  be 
microprogrammable,  microcodes  have  to  be 
prepared.  In  order  to  generate  microcodes 
efficiently,  a  microcode  compiler  is 
needed.  Currently  each  VHSIC  contractor 
has  his  own  approach  to  preparing  the 
microcodes  for  his  particular  VHSIC  chip 
architecture  design. 

At  Honeywell,  a  microcode  compiler 
for  the  EOSP  chip  set  has  been  completed. 
It  uses  a  high  level  Ada-like  language 
called  HML.  The  compiler  is  hosted  on  a 
VAX/780.  In  the  near  future,  there  are 
plans  to  extend  the  capability  of  the 
microcode  compiler  to  enable  it  to  be 
retargetable  to  other  architectures  more 
conveniently,  to  extend  the  versatility  of 
the  language  (HML)  and  to  generate  more 
optional  code. 

A  versatile  and  efficient  microcode 
compiler  is  essential  as  VHSIC  chips  find 
wider  applications. 

Computer  Aided  Bpsisn  Support  Tools . 
One  of  the  side  benefits  of  DoD's  VHSIC 
programs  is  the  development  of  various  CAD 
support  tools.  In  order  to  successfully 
fabricate  VHSIC  chips,  the  VHSIC 
contractors  had  to  upgrade  their  CAD 
systems  to  meet  VHSIC  Phase  1  goals. 
These  CAD  tools  will  then  be  delivered  to 
DoD  to  support  the  future  development  of 
ICA's. 

At  Honeywell,  the  CAD  system 
utilities  for  VHSIC  is  called  the  Advanced 
Integrated  Design  Automation  (AIDA) 
system.  The  development  of  the  AIDA 
system  can  be  divided  into  two  stages. 
The  first  stage  (AIDA  I)  has  been 
completed  and  is  being  used  for  the  VHSIC 
Phase  1  design.  In  the  AIDA  I  system,  the 
data  base  is  in  the  form  of  a  collection 
of  files.  The  second  stage  (AIDA  II)  is 
expected  to  be  completed  by  the  end  of 
VHSIC  Phase  1  and  is  to  be  a  VHSIC  Phase  1 
deliverable  to  the  Government.  For  AIDA 


II,  there  will  he  an  integrated  data  base 
which  will  facilitate  the  design  process 
via  remote  design  centers. 

The  Honeywell  AIDA  system  is  based  on 
a  hierarchical  approach  with  the  design 
process  dividing  into  various  levels, 
namely;  gate,  macrocell,  functional 
blocks,  chip  and  system  levels.  With  the 
incorporation  of  an  integrated  data  base 
system  and  one  single  hardware  description 
language  (HDL) ,  the  AIDA  system  will  be  a 
very  powerful  and  versatile  CAD  support 
tool  system  for  VHSIC. 

Procurement  Options.  One  of  the 
questions  that  is  frequently  brought  up  is 
that  of  procurement  options;  that  is,  how 
is  the  VHSIC  technology  to  be  made 
available  to  the  various  users?  To  answer 
this  question,  each  VHSIC  contractor  has 
to  formulate  an  approach  to  answer  this 
question. 

A  typical  approach  to  accomplish  this 
objective  is  to  provide  a  full  range  of 
services  ranging  from  sale  of  chips  to 
various  design  and  processing  options. 
This  may  be  further  facilitated  by  some 
developers  design  approach  which  includes 
the  use  of  a  macrocell  type  design 
methodology,  a  complete  CAD  system,  and 
distributed  design  centers. 

The  VHSIC  design  and  processing 
functions  can  be  illustrated  by  the  flow 
diagram  shown  in  Figure  2.  The  VHSIC  chip 
development  process  can  be  divided  into 
five  stages;  conceptual  design,  system 
design,  chip  design,  processing,  and 
finally  packaging/testing. 


system  chip 
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Figure  2.  VHSIC  Design  and  Processing 
Functions 

It  is  conceivable  that  with  this 
approach  the  developers  could  provide  four 
different  service  options  to  the  VHSIC 
users.  They  are  described  as  follows: 

Option  1.  The  conceptual  design 
could  be  performed  by  the  customer.  The 
VHSIC  supplier  will  provide  the  customer 
with  the  necessary  VHSIC  technology: 
performance  descriptions,  power 
requirements,  and  VHSIC  library  listings. 
The  customer  will  then  generate  the 
appropriate  systems  specifications  and  the 
VHSIC  supplier  will  perform  the  rest  of 
the  design  and  processing  functions. 


Option  2.  The  customer  will  perform 
both  the  conceptual  design  and  the  system 
design.  In  addition  to  the  VHSIC 
technology  description,  the  VHSIC  supplier 
may  also  provide  the  customer  with  access 
to  their  VHSIC  chip  library,  the  macrocell 
library  if  available,  and  the  necessary 
CAD  tools  for  system  design.  The  customer 
will  then  generate  and  provide  to  the 
supplier  the  chip  specification  for  chip 
design,  layout  mask  fabrication, 
processing,  packaging,  and  testing. 

Option  3.  For  this  option,  all  the 
design  work  could  be  performed  by  the 
customer,  with  the  VHSIC  supplier 
providing  the  necessary  design  rules, 
access  to  the  macrocell  library,  and  CAD 
tools  for  chip  design.  The  customer  will 
then  generate  and  present  the  supplier 
with  the  appropriate  digitized  layout  tape 
and  test  and  design  check  tools.  The 
supplier  will  do  the  IC  processing, 
packaging,  and  testing. 

Option  4.  For  this  option,  the  VHSIC 
supplier  would  provide  a  silicon  foundry 
service  whereby  they  will  receive  from  the 
customer  the  necessary  artwork  tape  to 
fabricate  and  process  the  VHSIC  IC's.  The 
customer  will  perform  all  the  design  work, 
and  will  get  back  from  the  supplier  the 
processed  wafers.  The  customer  will 
provide  for  their  own  packaging  and 
testing  functions. 

VHSIC  Status  Summary 

Those  elements  of  the  status  above 

which  are  relevant  to  the  insertion  of 

VHSIC  technology  into  operational 
equipment  and  training  devices  are: 

o  The  Phase  1  developed  1.25  micron 
geometry  IC's  are  directly 
applicable  to  military  systems  — 
including  training  devices. 

o  One  of  the  Phase  2  submicron 
objectives  is  to  provide  VHSIC 
Insertion  into  Weapon  Systems. 

o  An  interoperability  concern  exists 
with  the  IC's  being  developed  by 
the  six  different  contractors 
which  is  presently  being  jointly 
addressed  by  the  Phase  1 

contractors  with  the  VHSIC  Phase  1 
office. 

o  Software  support  is  also  unique 
for  each  of  the  six  contractors. 

o  IC's  can  be  procured  in  a  variety 
of  manners  —  from  preparation  of 
system  design  concept 

specifications  through  the 
ordering  of  'standard'  chips. 

The  status  of  the  VHSIC  program  can 
be  summarized  as  follows:  VHSIC  as  a 

technology  is  here,  the  problems  have  been 
clearly  defined,  and  solutions  are  being 
developed.  VHSIC  as  a  culture  has  not  yet 


been  examined  by  the  majority  of  the 
users.  The  question  before  us  is  what  are 
the  impacts,  and  how  do  we  respond? 

The  implication  of  VHSIC  to  trainers 
is  shown  in  Figure  3.  VHSIC  as  inserted 
into  weapon  systems  will  impact  both  the 
system  capabilities  and  employment,  thus 
requiring  new  training  requirements  and 
approaches.  VHSIC  as  inserted  into 
Maintenance,  will  allow  new  trainer 
concepts  and  capabilities.  Both  avenues 
of  VHSIC  Insertion  impact  will  result  in 
improved  training. 

THE  VHSIC  FOR  TRAINING  SYSTEMS  STUDY 

The  objectives  of  the  study  performed 
by  Honeywell's  Training  and  Control 
Systems  Operations  were  to  identify  the 
impact  VHSIC  would  have  on  Training 
Systems,  and  to  develop  an  approach  for 
coping  with  this  new  technology.  The 
impetus  to  the  study  was  to  answer  the 
questions  "VHSIC  is  here,  how  do  we 
respond?"  It  was  felt  that  we  need  to 
prepare  for  the  training  impact  caused  by 
VHSIC  insertion  into  Weapon  Systems,  plat¬ 
forms,  we  need  VHSIC  to  solve  some  persis¬ 
tent  high  priority  training  problems  and 
training  must  take  full  advantage  of  the 
new  technology. 


Specifically,  the  goals  of  the  study 

were : 

o  Identify  classes  of  operational 
equipment  for  which  VHSIC  technol¬ 
ogy  is  considered  appropriate, 
that  is,  VHSIC  Insertion  candi¬ 
dates  . 

o  Select  specific  candidates  to 
explore  in  general  terms  the 
impact  of  VHSIC  Insertion  on 
operation  and  maintenance. 

o  Evaluate  the  skill  changes  for 
these  candidates  for  use  in 
determining  the  impact. 

o  Identify  the  changes  in  training 
requirements  which  will  be 
necessitated  by  VHSIC  insertion 
into  operational  equipment. 

o  Identify  those  training 

requirements  which  result  from 
persistent  training  needs. 

o  Identify  the  training  device 
requirements  which  will  be  needed 
to  support  the  evolving  training 
requirements. 


Figure  3.  VHSIC  Relationship  to  Training 


o  Develop  an  application  approach  to 
meeting  the  new  training  needs. 


o  Decreased 
operation 


equipment 


manual 


o  Characterize  a  concept  which 

results  from  the  approach. 

o  Identify  recommendations  related 
to  further  development  of  the 

concept. 

VHSIC  Technology  Imgac.t  on  Operational 
Equipment 

The  determination  of  the  impact  of 
VHSIC  technology  insertion  into 

operational  equipment  was  made  to  identify 
the  skills  necessary  to  operate  and 

maintain  VHSIC  based  equipment.  Figure  4 
illustrates  the  major  milestones  in  the 
VHSIC  program.  The  approach  to  skill 
identification  was  conducted  in  two 

phases. 

The  first  phase  identified  the 

classes  of  operational  equipment  for  which 

VHSIC  technology  is  considered  appro¬ 
priate,  that  is,  VHSIC  Insertion  candi¬ 
dates.  The  second  phase  identified  the 

types  of  skills  or  changes  in  skills 
necessary  to  operate  and  maintain  the 
insertion  candidates. 

The  results  of  the  second  phase 
indicated  that  skill  changes  will  occur 
for  three  types  of  personnel:  equipment 

operators,  maintenance  technicians,  and 
operator  teams. 

Equipment  Operator  Skills: 

o  Proficiency  on  several  pieces  of 
equipment 

o  Increased  tactical  decision 
capability 


o  Addition  of  simple  maintenance 
skills 

Maintenance  Technician  Skills: 

o  Two  skill  levels  will  be  required: 

o  Operator/Maintainer  to 

interpret  BIT  displays  and 
perform  remove  and  replace 
tasks 

o  Expert  technician  to  perform 
tasks  beyond  the  level  of  BIT 
repairs 

Operator  Team  Skills: 

o  Increase  in  shared  tactical 
responsibilities 

o  Increased  emphasis  on  communica¬ 
tion  and  coordination 

o  Emphasis  on  skill  retention 

VHSIC  Technology  Impact  on  Training 

The  development  of  VHSIC  technology 
has  prompted  the  Naval  Training  Equipment 
Center  to  identify  two  important  issues 
driving  changes  in  training  requirements: 

1.  The  need  to  prepare  for  the 
training  impact  caused  by  the  use 
of  VHSIC  technology  in  weapon 
systems  platforms,  and 

2.  The  solution  of  some  of  the 
persistent  problems  which  have 
inhibited  effective  training. 


Figure  4.  Milestones  for  DoD  VHSIC  Program  (Take  from  Military 
Electronics/Countermeasures,  December  1981) 


The  approach  to  identifying  changes 
in  training  requirements  was  as  follows: 

o  Identify  the  changes  in  training 

requirements  necessitated  by  VHSIC 
insertion  into  operational 
equipment. 

o  Identify  training  requirements 
resulting  from  persistent  training 
problems. 

o  Specify  the  training  device 

requirements  needed  to  support 
evolving  training  requirements. 

The  training  changes  identified 
(Figure  5)  to  accommodate  skill  changes 
for  equipment  operators,  maintenance 

technicians,  and  operator  teams  were  as 
follows: 

Equipment  Operator  Training: 

o  From  less  emphasis  on  routine 
tasks  to  more  emphasis  on  quick 
decision  making. 

o  More  emphasis  on  cross-training  to 
acquire  multiple  equipment  skills. 

Maintenance  Technician  Training: 

o  More  emphasis  on  simple  mechanical 
skills  to  support  equipment 

maintenance  at  a  BIT 

interpretation  and  remove-and- 
replace  repair  level. 

o  Basic  technician  will  be  replaced 
by  an  Operator/Maintainer . 

o  The  expert  technician  will  receive 
more  emphasis  on  complex  trouble¬ 
shooting,  detailed  fault 

isolation,  and  in-depth  system 


understanding  and  theory  of 
operation. 

Operator  Team  Training: 

o  More  emphasis  on  communication  and 
coordination  skills  to  support 
team  training. 

o  More  wargaming  exercises. 

VHSIC  will,  therefore,  significantly 
change  the  roles  of  equipment  operators 
and  roaintainers.  With  the  significant 
increases  in  weapon  system  computing  power 
and  speed,  coupled  with  the  significant 
reductions  in  electronic  assembly  size, 
operators  will  now  become  more  tactical 
decision  makers,  and  maintainers  will 
follow  more  structured  and  automated 
checkout  procedures.  The  following  is  a 
summary  of  such  predicted  changes. 

Offensive  Weapon  £yit£ID  Role  Changes . 
As  a  result,  future  offensive  weapons  will 
be  autonomous  after  launch  (i.e.,  fire  and 
target),  and,  in  the  distant  future,  even 
before  launch.  Weapon  autonomy  will 
improve  the  survivability  of  the  launching 
platform  due  to  the  shortened  exposure 
time . 

In  addition,  VHSIC  based  weapon 
systems  will  be  more  reliable,  easier  to 
maintain,  and  have  a  higher  inherent 
availability  (Ai).  These  improvements 
will  be  due  to  the  high  reliability  of 
VHSIC  chips,  the  decreased  size  and  number 
of  components  which  result  from  VHSIC 
insertion,  and  a  more  extensive  use  of 
Built-In-Test  Equipment  (BITE) . 

The  use  of  more  BITE  will  improve  the 
maintainer's  ability  to  isolate  and 
replace  faulty  components  or  units.  Size 
and  quantity  reductions  will  reduce  the 


Figure  5.  Roadmap  for  Skill  Changes 


time  to  repair,  higher  reliability  will 
decrease  the  failure  rate,  and  thus  Ai 
will  increase. 

fi£l£  Change  lax.  lli£  Offensive  Weapon 
QpfiXittflX.  The  change  foreseen  in  the 
offensive  weapon  operator  role  will  be 
from  that  associated  with  weapon  control 
to  that  associated  with  a  tactical 
decision  capability.  The  time  gained 
through  the  use  of  a  f ire-and-f orget  type 
munition  will  be  used  for  combat  scenario 
assessment,  multiple  target  selection, 
survivability  tactics,  etc. 

Role  Change  for  the  Offensive  Weapon 
Maintainer .  The  change  foreseen  in  the 
role  of  the  offensive  weapon  maintainer 
will  be  from  that  associated  with 
troubleshooting  and  repair  to  that 
associated  with  interpreting  BIT 
indications  and  performing  routine  remove 
and  replace  actions.  Cases  beyond  BIT 
fault  isolation,  although  relatively  fewer 
in  incidence,  will  require  more  knowledge 
and  skill  on  the  part  of  the  maintainers. 

Role  Change  fox  the  Offensive  Weapon 
Team.  This  change  will  require  a  higher 
degree  of  shared  tactical  responsibility 
—  a  trend  now  evident  in  modern  weapon 
systems . 

Defensive  Weapon  System  Role  Change. 
Major  conflicts  in  the  future  will  be 
manifested  by  multiple  threats  from 
different  enemy  platforms.  The  positive, 
early  detection  of  such  a  scenario  can  be 
enhanced  through  the  use  of  defensive 
systems  which  are  capable  of  detecting, 
acquiring,  classifying  and  tracking  a 
large  number  of  threats.  The  use  of  VHSIC 
technology  can  provide  the  data  processing 
power  necessary  to  automate  all  of  these 
functions. 

Bfilfi  Change  fax  ths  Defensive  System 
Operator.  The  role  change  foreseen  for 
the  operator  of  a  defensive  system,  such 
as  a  search  and  surveillance  radar,  will 
be  from  a  control  manipulator  to  a  tactics 
decision  maker. 

In  addition,  it  should  be  possible 
for  one  operator  to  oversee  several  pieces 
of  automated  equipment.  This  capability 
will  reduce  manning  requirements  and/or 
serve  as  a  casualty  response  during 
battle. 

Rfilfi  Change  fox  thfi  Defensive  Weapon 
Team.  The  defensive  weapon  team  role  will 
change  from  a  detection/reaction  role  to  a 
more  effective  reaction  role  which  is 
responsive  to  multiple  threat  scenarios. 
This  change  will  require  better 
communication  and  coordination  between 
members  of  a  weapon  system  and  between 
teams  aboard  a  multi-weapon  system 
platform. 


Impac-t  on  Training  and  Training  Eni’icaa 

As  VHSIC  is  introduced  into  the 
weapon  system  design,  the  above  changes  in 
roles  are  forecast  to  result.  These  will, 
in  turn,  necessitate  changes  in  the 
training  techniques  and  devices  used  to 
support  the  weapon  systems.  It  is  not  a 
direct  conclusion  that  training  and 
training  devices  will  become  more  complex. 
Rather,  they  will  employ  different 
features  and  functions  which  are  not 
necessarily  more  difficult  to  simulate. 
Since  simulators  generally  simulate  only 
what  is  seen  by  the  operator,  not  how  the 
equipment  functions,  training  devices  may, 
in  fact,  become  simpler.  Because  the 
weapon  system  will  process  many  more 
sensor  inputs,  reduce  the  data  to  a  summay 
form  and  require  decision  making  on  the 
part  of  the  operator,  the  simulated 
information  presented  to  the  trainee  may 
be  less  complex  than  today's  training 
devices . 

In  the  case  of  stimulated  training 
devices  such  as  sonar  systems  having 
synthetically  generated  signal  sources 
driving  an  operational  equipment  mockup, 
the  training  device  design  may  also  be 
simpler.  Through  the  use  of  VHSIC  compo¬ 
nents  in  the  design  of  the  training  de¬ 
vice,  ocean  and  target  modeling  may,  in 
fact,  be  simpler  than  today.  Computation¬ 
al  bounds  on  speed  and  size  may  be  re¬ 
solved  through  the  use  of  VHSIC  components 
in  new  distributed  architectures. 

It  is,  therefore,  anticipated  that 
the  introduction  of  VHSIC  into  weapon 
systems  will  not  make  the  training  system 
design  more  difficult.  It  will,  however, 
be  different  and  we  must  anticipate  these 
impacts  in  our  training  system 
requirements  and  designs.  We  must  stay 
abreast  of  the  technology  advances  to 
ensure  that  training  systems  ensure 
student  and  weapon  system  readiness. 

The  concluding  part  of  the  study  was 
conducted  to  identify  how  VHSIC  technology 
can  be  applied  to  the  design  of  training 
devices.  The  approach  to  application  was: 

o  Identification  of  appropriate 
VHSIC  attributes. 

o  Selection  of  VHSIC  Insertion 
training  device  candidates  from 
the  identified  training  device 
needs. 

o  Development  of  an  application 
approach. 

o  Characterization  of  a  concept 
which  resulted  from  the  approach. 

o  Identif ication  of  recommendations 
related  to  further  development  of 
the  concept. 


This  approach  led  to  specific  VHSIC 
application  areas,  to  a  generic  method  of 
providing  VHSIC  Insertion  cost 
effectiveness  to  the  selection  of  a  prime 
candidate  training  system,  and  to  a  set  of 
recommendations  for  the  pursuit  of 
achieving  VHSIC  insertion  into  training 
devices. 

The  conclusions  of  the  study 
identified  specific  areas  where  VHSIC 
could  benefit  the  design  and  performance 
of  training  devices.  These  benefits  were 
primarily  in  the  areas  of  size,  speed, 
cost,  and  reliability. 

The  reduced  size  of  VHSIC  IC's 
currently  in  development  (1.25  micron 
feature  size)  permits  a  veriety  of  new 
applications  and  capabilities.  Today's 
complex  system  trainers  such  as  flight 
simulators,  tactics  trainers,  and  ASW 
trainers  involve  many  racks  of  electronic 
equipment.  This  large  hardware  complement 
requires  significant  dedicated  facilities, 
cooling,  and  power.  Through  the 
introduction  of  VHSIC  components  into  the 
system  design,  significant  reductions  in 
equipment  size,  even  approaching  or 
exceeding  fifty  percent,  are  possible  by 
the  late  1980’s.  These  hardware 
reductions  will  also  impact  system  and 
facility  support  costs  through  reduced 
maintenance,  cooling,  and  power  require¬ 
ments. 

The  use  of  VHSIC  components  will 
impact  system  cost  by  combining  many 
different  circuit  functions  on  a  single 
chip.  This,  in  turn,  will  reduce  the 
number  of  circuit  boards,  card  frames,  and 
equipment  racks.  Distributed  processing 
designs  will  be  both  practical  and  cost 
effective.  However,  it  remains  question¬ 
able  whether  true  system  cost  savings  will 
be  achieved  due  to  the  increased  function¬ 
ality  possible.  It  is  likely  that  the 
added  computing  capability  possible  with 
VHSIC  will  be  used  to  enhance  the  training 
device  effectiveness,  thus  making  up  for 
the  inherent  cost  reduction  through  more 
compact,  efficient  system  design. 

There  exists  today  a  variety  of 
persistent  high  priority  training  problems 
which  cannot  be  solved  with  today’s  VLSI 
technology.  The  sheer  amount  of 
computations  for  many  of  today's  training 
devices  limit  their  ability  to 
realistically  perform  in  real  time.  NTEC 
has  identified  eight  training  device  areas 
which  are  presently  capacity  or  speed 
limited  by  current  technology: 

1.  Dynamic  Target  Modeling 

2.  Real  Time  scenario  Event  Control 

3.  Intelligent  Adversary  Modeling 
(Responsive  Targets) 

4.  Computer  Aided  Instruction  (CAI) 
and  Computer  Managed  Instruction 
(CMI)  Modeling 


5.  Environmental  Modeling 

6.  Acoustic  Modeling 

7.  Image  Scene  Generators 

8.  Organic  (Built-in)  Training  Capa¬ 
bilities  in  Tactical  Equipment 

Through  VHSIC,  it  will  be  possible  to 
significantly  increase  the  realism  of 
weapon  system  trainers  through  more 
detailed  real  time  computation  and 
simulation  of  the  operational  environment. 
The  limitations  of  size  and  speed  have 
precluded  effective  organic  training. 
These  same  problems  have  limited  the 
development  of  highly  effective,  field- 
portable  training  devices.  Tactical 
environments  and  power  constraints  have 
limited  the  use  of  large  portable  vans  in 
the  field.  Through  VHSIC,  small  hand-held 
portable  devices  can  be  displayed  which 
will  provide  highly  effective  training. 
Both  organic  and  strap-on  training 
approaches  will  become  a  practical 
reality.  As  the  use  of  Artificial 
Intelligence  (AI)  technology  emerges  into 
an  application  phase,  VHSIC  technology 
will  become  an  integral  part  of  the  AI 
application  into  training  devices.  VHSIC 
will  significantly  aid  the  training  system 
designer  in  meeting  the  evolving  needs  of 
future  weapon  systems. 

Through  the  study,  it  emerged  that  a 
high  payoff  area  for  the  introduction  of 
VHSIC  into  training  systems  was  in  the 
area  of  visual  simulation  systems.  In 
computer  image  generation  (CIG) ,  a  present 
limiting  factor  to  the  number  of  polygons 
(image  detail)  generated  is  the  ability  to 
process  in  real  time  the  various 
algorithms  making  up  the  simulated  image. 
Through  the  use  of  VHSIC  hardware  and 
architectures,  it  will  be  possible  to 
significantly  improve  image  resolution  and 
quality.  It  was  recommended  that  this 
area  be  explored  further  as  the  first 
candidate  application  of  VHSIC. 

It  was  determined  in  this  study  that 
a  generic  core  set  of  VHSIC  chips  could 
meet  the  requirements  of  a  large  majority 
of  training  devices.  Through  an  examina¬ 
tion  of  common  computation/processing 
requirements  found  in  a  variety  of 
different  training  device  applications,  a 
common  core  of  VHSIC  chip  requirements  was 
identified.  This  common  core,  called  the 
Training  Chip  Set  or  TCS,  was  further 
defined  to  determine  its  optimal 
configuration  to  meet  this  diverse  range 
of  training  device  applications.  A  key 
conclusion  of  the  study  was,  therefore, 
the  need  for  the  development  and 
application  of  this  generic  chip  set  to 
training  devices. 

THE  TCS  -  WHAT  IS  IT? 

The  approach  to  the  TCS  concept  was 
based  upon  measurable  design  and 
development  goals. 


Three  design  goals  were  established. 


reasonable  initial 
marginal  cost. 


cost  and 


minimal 


Performance.  The  measure  of 
performance  was  taken  as  data  throughput 
expressed  as  Millions  of  computer 
Instructions  Per  Second  (MIPS) .  The  goal 
was  to  achieve  an  order  of  magnitude 
greater  than  that  for  devices  using 
conventional  technology,  with  an  absolute 
goal  of  not  less  than  10  MIPS. 

Size .  The  goal  was  to  reduce  by  an 
order  of  magnitude  the  volumes  of 
conventional  devices.  This  change  in  size 
would  permit  desk-top  simulators  which  now 
occupy  cabinets,  or  from  a  desk-top  size 
to  a  hand-held  device. 

Cost.  The  goal  was  to  achieve  a  50 
percent  reduction  in  the  Life  Cycle  Cost 
(LCC)  of  conventional  technology  based 
devices . 

Development  Goals 

The  following  four  development  goals 
were  considered. 

1.  A  single  development  effort 
should  be  pursued  to  achieve  a  universal 
set  of  VHSIC  chips  applicable  to  training 
devices.  The  benefits  are  obvious:  lower 
cost  and  higher  priority  position  in  a 
critical  technology. 

2.  The  chip  design  should  have  the 
capability  to  provide  functionality  for 
all  foreseen  applications.  In  addition  to 
meeting  the  needs  of  the  entire 
instructional  environment,  the  designs 
should  not  be  platform  unique  (i.e.,  only 
classroom  trainers) . 

3.  The  chips  and  the  design  process 
should  be  available  to  the  entire  training 
community.  This  includes  Joint  Service 
access  and  use  by  all  device  designers. 

4.  The  design  of  the  chips  should 
fully  incorporate  existing  VHSIC 
technology.  This  includes  not  only 
specific  chip  designs,  but  also  design 
techniques  and  tools,  fabrication 
techniques,  and  testing  techniques. 

The  identification  of  this  set  of 
goals  set  the  stage  for  the  major  effort 
of  the  study  —  the  VHSIC  implementation 
technique. 

VttSIC  Implementation 

The  benefits  of  VHSIC  technology  to 
training  devices  are  profound  and 
numerous.  However,  successful  insertion 
of  VHSIC  technology  into  training  systems 
will  have  to  be  made  in  a  timely  and  cost 
effective  manner.  The  Training  Chip  Set 
(TCS)  concept  developed  under  this  study 
allows  the  insertion  of  VHSIC  technology 
into  a  variety  of  Training  Systems  at  a 


The  goals  of  developing  a  TCS  were: 

1.  Modularity  to  allow  application 
to  various  current  systems  and  to  allow 
expansion  to  future  training  systems. 

2.  Separation  of  functions  to 
simultaneously  allow  flexibility  (i.e., 
programmability)  and  high  throughput. 

The  training  chip  set  concept  is 
depicted  in  Figure  6.  For  any  given 
training  system,  the  TCS  will  consist  of 
two  major  portions:  the  core  controller 
and  the  adjuncts  specific  to  that 
particular  training  system. 

The  insertion  of  VHSIC  technology 
into  a  particular  training  system  will 
consist  of  several  core  controllers  (each 
of  which  consists  of  several  VHSIC  chips 
as  described  later)  and  a  much  larger 
number  of  adjuncts  (each  one  of  which  will 
be  typically  implemented  using  a  single 
VHSIC  chip).  In  this  configuration,  each 
core  controller  will  control  several 
adjunct  chips.  The  number  of  adjuncts 
which  can  be  controlled  by  a  core 
controller  depends  upon  data  rates  in  a 
specific  training  system  and  will 
typically  vary  for  different  training 
systems. 

The  core  controller  is  highly 
programmable  and  thus  allows  flexibility 
to  accommodate  changes  and  updates  in  the 
functioning  of  the  training  system.  The 
adjunct (s)  are  directly  in  the  path  of  the 
data  flow  and  provide  very  high  throughput 
operations  on  the  data.  Thus,  the  goal  of 
high  throughput  together  with 
programmability  is  achieved. 

Under  this  study,  we  have  evaluated 
the  applicability  of  the  TCS  concept  to 
two  training  systems.  These  are: 

1.  Computer  Generated  Synthesized 
Imagery  (CGSI). 

2.  Anti-Submarine  Warfare  Trainer 
(ASW  Trainer ) . 

The  CGSI  system  is  being  developed 
for  more  realistic  visual  training  and  the 
use  of  VHSIC  technology  will  allow  real- 
tirtie  operation  of  a  complex,  multi-channel 
CGSI  system.  The  ASW  trainer  is  the 
traditional  sonar  trainer  and  the 
insertion  of  VHSIC  technology  will 
dramatically  reduce  the  size  of  sonar 
trainers. 

Preliminary  design  of  a  one  chip  CGSI 
adjunct  VHSIC  chip  and  a  one-chip  ASW 
adjunct  have  been  completed.  Preliminary 
estimates  show  that  a  controller, 
implemented  using  four  VHSIC  chips,  will 
be  able  to  control  up  to  100  CGSI  or  ASW 
adjunct  chips. 


Figure  6.  Training  Chip  Set  Adjunct  Concept 


The  modular  approach  to  the  TCS  will 
allow  the  application  of  VHSIC  technology 
to  other  training  systems  by  using  the 
controller  and  new  adjunct (s)  specifically 
designed  for  these  training  systems. 
Thus,  the  meaningful  cost  of  inserting  the 
VHSIC  technology  into  future  training 
systems  will  be  drastically  reduced. 

SUMMARY 

The  primary  goal  of  the  NTEC  VFTS 
study  was  to  determine  the  impact  of  the 
DoD  VHSIC  program  on  weapons  systems, 
training  and  training  devices  and  to 
derive  a  comprehensive  impact  assessment. 
This  goal  has  been  achieved  and,  in 
addition,  the  concept  of  a  VHSIC  Training 
Chip  Set  (TCS)  evolved  as  the  study 
progressed. 

The  availability  of  proven  VHSIC 
components  for  insertion  in  weapon  systems 
can  occur  as  early  as  1986.  New  and 
different  training  devices  and  training 
capabilities  will  be  required  tc  meet  the 
training  needs  of  the  future;  the  Train¬ 
ing  Chip  Set  —  can  meet  the  requirements 
of  a  large  majority  of  these  requirements. 

Increased  system  performance  of  VHSIC 
technology  provides  the  forecast  of 
increased  system  performance  and 
reliability  in  diverse  application.  Both 
training  requirements  and  trainers  will 


change.  In  particular,  performance, 
physical  characteristics  and  projected 
cost  of  VHSIC  technology  under  development 
will  significantly  improve  present  and 
future  training  devices.  This  basic  tech¬ 
nology  could  become  available  as  early  as 
1985  for  the  1.25  micron  feature  size 
IC’s.  The  increased  performance  of  a 
VHSIC  TCS  will  result  in  fewer  unique 
designs  in  support  of  trainers  and  there¬ 
fore  shorter  design  times.  VHSIC  technol¬ 
ogy  embededed  in  the  design  of  a  core 
generic  training  chip  (TCS)  should  be 
capable  of  supporting  approximately  80*  of 
the  processing  computation  and  control 
requirements  of  any  trainer. 

Potential  applications  of  the  TCS 
encompass  training  requirements  for  all 
military  services  and  should  be  addressed 
as  a  future  joint  service  program  for 
insertion.  The  core  TCS  has  been 
conceived  to  support  all  foreseen 
applications  since  it  is  not  platform 
unique,  service  unique  or  limited  by 
performance  constraints  that  could 
conceivably  result  in  early  or  premature 
obsolenscence.  The  requirements  of  chip 
sets  for  adjunct  functions  (e.g.,  visual, 
ASW  simulation,  etc.)  may  be  unique. 
However,  in  many  applications  the  TCS  can 
support  the  total  real-time  processing 
requirements  of  some  trainers,  and  thus 
not  require  adjunct  chip  developments. 


In  summary  the  VHSIC  technology  is 
upon  us,  its  impact  is  expected  to  be 
significant,  and  its  benefits  plentiful. 
VHSIC  will  impact  skills,  training 
concepts  as  well  as  trainer  devices.  It 
is  imperative  that  we  recognize  VHSIC's 
potential,  and  begin  developing  plans  and 
techniques  for  implementing  these  new 
concepts . 
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ABSTRACT 


Microprocessors  are  already  embedded  in  Aircrew  Training 
Devices  (ATDs)  for  display  generation,  input/output  control,  and 
other  special  purpose  applications.  This  paper  deals  with  the  key 
factors  relating  to  the  use  of  microprocessor  systems  (rather  than 
minicomputers)  in  performing  the  central  computational  function  for 
ATDs.  Such  factors  include  key  performance  parameters  to  be 
considered  when  replacing  a  32-bit  minicomputer  by  a  system  of 
microprocessor s ;  requirements  for  a  recent  Air  Force  ATD  system; 
benchmarks  for  computational  performance;  and  specific  changes  to  ATD 
prime  item  development  spec i f icat ions > 


INTRODUCTION 

To  limit  the  scope  of  technical 
activity  to  reasonable  bounds,  the 
C5A/C141  Aerial  Refueling  Part  Task 
Trainer  ( ARPTT)  was  chosen  as  an  example 
for  which  micros  might  be  used.  A  recent 
draft  Request  for  Proposal  for  this 
system  was  used  as  guidance  in  this  study. 
Data  from  comparable  systems  were  used  to 
estimate  the  C5A/C141  ARPTT  computaton 
requirements.  A  "sizing"  exercise  based 
on  the  B-52  ARPTT  using  micros  to  satisfy 
computational  requirements  was  performed. 
This  exercise  plus  considerable 

information  from  microprocessor  vendors 
provides  the  bulk  of  the  data  presented 
here.  Such  technical  and  performance  data 
are  summarized. 

KEY  PERFORMANCE  PARAMETERS 

The  key  parameters  for  distributed 
microprocessor  systems  are  similar  to 
those  for  minicomputer  systems.  These  are 
discussed  below. 


1.  Floating  Point.  Real-time  simulator 
performance  requires  mathematical  comput¬ 
ing  in  floating  point  to  solve  the  large, 
highly  accurate  flight  and  aerodynamic 
equations.  Because  of  the  precision, 

accuracy,  and  numerical  range  of  these 
equations,  the  numbers  involved  require  32 
bits  or  more  of  representation.  Thus,  the 
arithmetic  computing  elements  must  have 
adequate  execution  times.  Software  float¬ 
ing  point  implementations  require  a 
fairly  large  number  of  instructions  which 
result  in  long  execution  times.  Hardware 
floating  point  implementation  requires 
only  a  few  instructions  with  the  actual 
floating  point  calculation  being  done  in 
hardware.  The  hardware  performance 


floating  point  is  approximately  100  times 
faster  than  a  software  implementation  of 
the  same  functions. 

2 .  Data  Bus  Considerations .  In  single  bus 
systems  all  commmun icat ion  activities  must 
use  the  system  bus  resource.  As  the  micro¬ 
processor  system  size  ard  performance 
levels  ircrease  (i.e.  as  more  micro¬ 
computers  are  added  to  the  bus)  to  meet 
larger  application  requirements,  the 
reserve  bus  bardwidth  becomes  depleted. 
Eventually,  as  the  system  computational 
capabilities  ard  resources  are  ircreased, 
the  total  system  performance  will  decrease 
due  to  inadequate  bus  capacity. 

In  systems  where  bus  cortrol 
excharges  are  synchronized  to  a  commor  bus 
clock,  no  data  will  be  lost  on  destroyed 
when  system  bus  reserve  bandwidth  is 
exceeded.  What  will  happen  is  the  system 
functions  demanding  system  bus  resources 
will  have  to  wait  lorger  periods  of  time 
to  be  serviced.  To  alleviate  this  situa¬ 
tion  specially  dedicated  buses  may  be 
added  to  relieve  the  single  bus  conges¬ 
tion  . 

Memory  buses  independent  of,  but 
coupled  to,  the  main  system  bus  by  dual 
ported  memories  play  a  large  role  ir 
increasing  the  main  system  bus  effective 
capacity.  This  is  extremely  important 
where  single  task  partitioning  amorg 
multiple  microprocessors  is  required  to 
obtain  specified  functional  performance 
levels . 

Multichannel,  I/O  buses  independent 
of,  but  coupled  to,  CPU  local  buses,  local 
memories,  I/O  peripherials ,  and  the  main 
system  bus  by  dual  ported  memories  and 
special  I/O  controllers  are  again  useful 
ir  reducirg  the  mair  system  bus  traffic. 
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Bus  bar-iwi  itn  is  the  .■  •■npu'-er  system 
trarsi'er  rate  oapabi  1  ity  to  iistr  ibjte 
data  a m o r g  vicious  s o u c  ’ o s  i r  :  J  -* s’  i  r  j - 
tiers  access  the  system  uus  er  oases.  It 
is  essertially  trie  lifeline  of  tne  •ouput- 
irg  system.  Wner  exceeded  by  various 
demards,  limitei  bardwidtri  degrades  the 
system  performance.  The  capability  to 
determire  the  reserve  bus  bardwi dtn  is  ar 
essertiol  requirement  ir  the  evalu  ilirr 
ard  desigr  phases  for  specific  distributed 
microprocessor  system  applications. 

3.  Execution  Times .  How  useful  are  micro¬ 
processor  execution  times  in  evaluating 
total  system  performance?  System 

performance  estimates  depend  very  strongly 
upon  what  tools  and  methods  are  used  to 
measure  and  analyze  the  execution  times. 

One  common  measure  of  microprocessor 
execution  performance  is  MIPS  (Millions  of 
Instructions  Per  Second).  The  MIPS  value 
states  only  the  number  of  instructions 
that  can  be  executed  in  a  unit  time. 
"MIPS"  ignores  the  type  of  instruction 
set,  internal  and  external  architectures, 
and  the  language  implementation  effici¬ 
encies  to  be  employed  for  a  specific 
system  application.  For  example,  a  low 
MIPS  microprocessor  with  a  powerful 
instruction  set  and  architecture  may  out¬ 
perform  a  high  MIPS  one  with  many 
instructions  and  limited  architecture.  In 
this  sense  MIPS  is  not  always  a  very 
precise  indicator  of  a  microprocessor's 
total  system  performance  capabilities. 

Benchmarks  are  special  programs 
written  to  determine  the  performance  of 
microprocessors  within  a  given  product 
line  or  between  diffeient  manufacturers. 
Benchmarks  can  be  a  better  technique  than 
"MIPS"  for  evaluating  microprocessor 
performances.  The  utility  of  a  benchmark, 
however,  depends  upon  the  source  of  the 
benchmark  and  the  purpose  it  is  intended 
to  cot.vey.  The  Whetstone  Benchmark  was 
developed  at  the  National  Physical 
Laboratory,  Teddington,  England,  to 
provide  a  meaningful  way  to  evaluate 
scientific  computational  performance  of 
machines  with  different  architectures  and 
language  implementations.  The  Whetstone 
Benchmark  has  a  good  mix  of  both  logical 
and  mathematical  instructions  to  provide 
an  indication  of  different  microprocessor 
performances  in  scientific  applications. 

Adequate  benchmarks  for  all  classes 
of  ATDs  do  not  presently  exist  due  to  the 
great  design  variability  possible  for  the 
software  for  a  given  ATD  implementation. 

4.  Memory  Cons  i  derations .  The  direct 
memory  addressing”  -  capability  of  a 
microprocessor  has  a  considerable  impact 
upon  the  total  system  capability  and 
performance.  The  more  extensive  tn** 
addressing  (coupled  with  proven  virtual 
memory  techniques  and  memory  management 
functions),  the  more  flexible  and 
adaptable  the  m icroprocessor  becomes, 


permitting  ■  wiJ.-r  rang,.*  at'  ufjVr-n' 
types  ‘  • ;  ;  .  .  ■  1 1  ,  ;  r  i  a  .  I  • '  J  ‘  *  1  " 

ad  ires:’,  mg  redu-’es  t  tie  bjriett  jm  u.f’wir,- 
engineers  la  Jesign  arjarij  ;r  y 

limit  ill  ms. 

M  era  ary  u  -j  .» g  e  c  an  b  e  _■  a  t  e  g  >  r  i .’  *•  i  nt  j 
two  types  (  1  > :  a  1  >r  private  and  1  -1  >  . 

Local  memory  capabilities  should  be  use  1 
as  much.  as  practical  u  enhance  the 
performance  and  expinsi  >r.  by  re  to  mg 
memory  dependence  and  traffic  on  tne  a  un 
system  bus.  Local  memory  us  ige  gen.-r  illy 
enhances  memory  access  time  oy  it)  la  -.oil 
over  that  of  global  memory  requiring  use 
of  tne  main  system  bus.  Mi or opr  a  cess  or s 
are  now  available  that  have  local  or 
private  memory  oupabi  l  ities  of  up  to  1  to 
megabytes.  Tnese  systems  are  dual  ported 
which  also  permits  partitioning  of  a  given 
memory  for  local  and  global  applications. 

5.  Systems.  Mioropro  lessor 

operating  systems  have "evolved  from  little 
more  than  hardware  monitors  to  the 
current  multitasking  and  multiprocessing 
types.  The  latest  operating  systems  are 
as  sopn i s t ica ted  and  powerful  as  those  for 
some  large  main  frames.  Furthermore, 
microprocessor  operating  systems  are  fully 
configurable  to  meet  the  system  and 
application  requirements.  The  newer 
microprocessors  have  many  of  the  operating 
system  elements  in  hardware  to  improve  the 
performance.  These  hardware  elements 
include  task  switching,  memory  management, 
and  interrupt  handlers. 

Operating  systems  for  micros  must  be 
configured  at  a  much  lower  level  of  detail 
than  those  for  minis.  This  activity 
requires  a  more  detailed  knowledge  of 
operating  systems  on  the  part  of  the  ATD 
contractor . 


MEETING  C5A/C141  ARPTT  REQUIREMENTS 

The  commercial  microprocessor 
products  which  have  the  potential  to 
satisfy  the  specified  C5A/141  ARPTT 
requirements  are  evaluated  below.  The 
requirements  which  must  be  fulfilled 
include  the  following:  (1)  all  system 
components  and  packages  are  currently 
available  in  off-the-shelf  form  and  on  a 
pi ug-together  basis,  (2)  multitasking  and 
multiprogramming  operating  systems  are 
complete  and  validated,  (3)  the  multipro¬ 
cessing  operating  system  is  complete 
and  validated,  (4)  FORTRAN  77  and  Assembly 
languages  are  available,  (5)  data  paths 
are  a  minimum  of  16  bits,  and  (6)  there 
exist  system  bus  hardware  arbitration, 
upward  compatibility  and  floating  point 
capability.  (See  Table  1  below). 
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HARDWARE 

BOARD 

LEVEL 

COPROCESSOR 

FLOATING 

POINT 

SYSTEM 

BUS 

ARBITRA¬ 

TION 

MEETS 

SPECS 

CITED 

MICRO 

PROCESSOR 

MULTI¬ 

TASKING 

MULTI¬ 

PROCESSING 

LANGUAGES 

VENDORS 

AVAILABLE 

INTEL 

8087 

287 

YES 

PRIORITY 

YES 

RMX-86 

RMX-38 

RMX-80 

MMX-800 

-MMX-80 

-MMX-86 

-MMX-88 

FORTRAN  77 

COBOL 

PASCAL 

BASIC 

PL/M 

ASSEMBLY 

NOW 

MASTER/ 

MASTER 

MOTOROLA 

MC6888  1 

YES 

PRIORITY 

LEVEL 

NO 

RMS-86K 

MSP/ 

68000 

4Q83 

FORTRAN  77 

COBOL 

ASSEMBLY 

4Q  83 

ZILOG 

4Q83 

NO 

NO 

ZEUS 

NONE 

AS  OF 

1  DEC  82 

FORTRAN 

ASSEMBLY 

TEXAS 

INSTRUMENTS 

1421 

FIRMWARE 
(BIT  SLICE) 

NOT 

COMPLETE 

NO 

RX 

NONE 

AS  OF 

1  DEC  82 

FORTRAN 

PASCAL 

BASIC 

ASSEMBLY 

NOW 

DIGITAL 

FPF-1 1 

YES 

MASTER/ 

SLAVE 

YES 

RSX-1  IS 

NONE 

FORTRAN 

ASSEMBLY 

BASIC 

COBOL 

EQUIPMENT 

NOW 

RSX-1  1M 

AS  OF 

1  DEC  83 

Evaluation  of  Vendor  Capabilities 
Programming  Language  and  Operating  System 
Table  1-1 


OPERATING 

SYSTEMS 

VENDORS 

MULTI 

PROCESSORS 
(16  Bit) 

LOCAL  AREA 

NETWORK 
(Optional ) 

MEETS  ALL 

SPECIFICA¬ 
TIONS  CITED 

INTEL 

8030 A  (8  Bit) 
8085A  (8  Bit) 
8088A 

8086A 

186 

286 

386  (32  Bit) 

ETHERNET 
( 10  Megabit) 

( 100  Stations) 
(500  Meters) 

YES 

MOTOROLA 

68000  Series 
(16/32) 

NO  INFO 

YES 

ZILOG 

Z  8000  Series 

Z  Net 

NO 

TEXAS 

INSTRUMENTS 

TMS-9900 

1481  BIT 

SLICE  SERIES 

IBM  SYSTEM 

NO 

DIGITAL 

EQUIPMENT 


LSI-11 

PDP-11  SERIES 


ETHERNET 
DEC  NET 


NO 


HARDWARE 

BOARD 

LEVEL 


MASS  STORASE 


LEVEL 

VENDORS 

HARD  DISK 
TO  330  M 
BYTES 

WINCHESTER 

TO  84  M 

BYTES 

MAGNETIC 

TAPE 

9-TRACK 

FLOPPY 

DISK 

SYSTEMS 

MAGNETIC 

TAPE 

CARTRIDGE 
TO  60  M 
BYTES 

BUBBLE 

MEMORY 

TO  512  K 
BYTES 

INTEL 

SBC-220 

SBC-215 

Independ¬ 

ent 

SBC-204 

SBC-208 

SBC-217 

SBC-251 

SBC-254-4 

YES 

YES 

Vendors 

YES 

YES 

YES 

YES 

MOTOROLA 

No  Info 

As  of 

1  Dec  82 

No  Info 

As  of 

1  Dec  82 

None 

Ind icated 

YES 

NO 

NO 

ZILOG 

None 

Indicated 

None 

Indicated 

Independ- 

Vendors 

YES 

NO 

NO 

TEXAS 

INST. 

NO 

Independent 

Vendors 

NO 

YES 

NO 

NO 

DIGITAL 

EQUIP. 

YES 

NO 

RTO 

Series 

YES 

YES 

YES 

Evaluation  of  Vendors  Capabilities 
Hardware  &  Peripherals 
Table  1-3 


1 •  E v a 1 u a t ion  o f  Individual  Manufacturers 


1.1  Texas  Instruments .  As  of 
February,  19817  T.I.  did  not  have  a 
multiprocessor  operating  system  nor 
microprocessor  floating  point  coprocessor 
available.  There  were  no  immediate 
development  plans. 


1-2  As  of  February,  1983, 
Zilog  had  no  multiprocessing  operating 
system  nor  hardware  floating  point 
processor  available.  There  were  no 
immediate  development  plans. 


1983,  Intel  was  the  only  company 
investigated  that  had  everything  to 
implement  a  complete  distributed 
microprocessor  system  meeting  the  ATD 
requirements.  Also  to  aid  in  the 
development  of  a  distributed  microproces¬ 
sor  system,  Intel  has  a  wide  variety  of 
ICE  (In  Circuit  Emulation)  systems. 
Intel  advertises  total  upward  compatibil¬ 
ity.  All  software  developed  for  the  8086 
microprocessor  is  upward  compatible  with 
the  8088,  80186,  80286  and  80386. 


BENCHMARKS 


1.3  Digital  Equipment  Corporation.  As 
of  February,  T583,  dFC  haS~a  variety  of 
hardware  available  but  did  not  have  a 
multiprocessing  operating  system  for  the 
LSI-11, 

1.4  Motorola .  Motorola  has  in 
development  a  multiprocessing  operating 
system  and  hardware  mathematics  coproces¬ 
sor  with  a  release  date  of  late  in  1983. 

’.5  Intel  Corporation.  As  of  early 


This  section  highlights  key  technical 
evaluations;  namely,  hardware  floating 
point  and  operating  systems  performance 
benchmarks . 

1  •  Intel  Benchmark .  The  data  supplied 
for  this  benchmark  was  obtained  from  Intel 
Corporation  to  show  the  Whetstone  floating 
point  performance  of  the  8086/8087  and 
80286/80287  microprocessor  systems.  The 
following  table  gives  this  data. 


MICRO 


COPROCESSOR 

MICRO  CLOCK  COPROCESSOR  CLOCK 


WHETSTONE 


APX-286/  10  8  mhz 

86/30  SBC  5  mhz 


80287  5mhz  150  KOPS 

8087  5mhz  100  KOPS 


Table  ? 

The  Whetstone  benchmark  unit  (KOPS) 
implies  thousands  of  floating  point 
operations  per  second.  The  APX-286/10  and 
the  86/30  are  single  board  computers  that 
may  be  purchased  off  the  shelf. 

The  architecture  of  the  above 


microsystems  is  such  that  the  8086/80286 
micros  perform  logic  and  data  access 
functions,  while  the  8087/80287  perform 
floating  point  calculations.  The  micros 
and  their  coprocessors  operate  in  mixed 
concurrent  and  parallel  modes. 


l] 


2.  Author ' s  Floatirg  Poirt  Software 
cBerchmark  CP.E.  S' 7 32  M i r  i  v s  ■ 

JS’6/2'8’7  Micro.  A  comparisor  is  made 
between  the  floatirg  poirt  performance  of 
a  Perkin  Elmer  8/32  minicomputer  used  in 
the  B52  Aerial  Refuelirg  Simulator  (1977 
vintage  minicomputer)  to  that  of  an  Irtel 
SBC  286-10  single  board  computer  with  a 
287  mathematics  coprocessor. 

Two  assembly  language  programs  were 
ceded  implementing  the  same  algorithm  for 
both  processors.  The  algorithm  implement¬ 
ed  is  a  randomly  chosen  flight  equatior 
used  in  the  B-52  ARPTT .  The  form  of  the 
equatior  is: 

Z  =  MgCos  Theta  Cos  Phi  +  Zs-Cos  X  +  Xs 
sinX  +  Zt 


The  overall  performance  factor  is  >.7 
to  1  for  this  example.  Note  that  the 
floatirg  poirt  time  ratio  is  8  to  1,  while 
the  table  search  is  j  to  1.  For  the  PE 
8/32D  the  Whetstore  ratirg  is  all 
KOPS,  whereas  the  Irtel  board  is  laj  K.iPE 
givirg  a  Whetstore  performance  ratio  of  o 
to  1.  Cor sequer 1 1 y  ,  the  real  performance 


ratio  betweer  the  PE  3/32D  used  or 
52  ARPTT  ard  the  Irtel  sirgle 


the  !■- 
boar  i 


computer  ranges  betweer  i  to  1  ai'J  -  t> 
dependirg  on  how  much  floatirg  point 
computation  is  designed  irto  the  software. 
The  key  poirt  her_e  i_s  Unit.  the  detail? 
the  software  desigr  i_t£el£  car  FrflaJerce 
substaFt FiXlTy  the  berchinark  comparisons. 
TheFe  Fs  FF  way  to  accurately  benchmark 
ATD  computer  performance  without  JetaiFeJ 
knowledge  of  the  software  design  approach . 


Neither  of  the  two  assembly  language 
programs  was  run  on  its  respective  target 
machine;  however,  it  is  felt  that  these 
programs  are  coded  sufficiently  well  for 
the  purpose  of  calculating  the  required 
execution  times. 


The  implementation  of  the  equation 
used  "table  look  up"  techniques  to  assess 
the  trigonometric  functions  where  the 
address  computations  are  not  done  in 
floating  point.  Consequently,  the  timirg 
is  represented  in  terms  of  floating  point 
and  table  search  as  shown  below. 


3.  RMX-86  Operating  System  Benchmark. 
This  section  cortairs  a  berchmaFk  whfch 
relates  the  performance  of  a  RMX-86  base 
operating  system  on  two  different  Irtel 
singe  board  computers.  One  implementation 
is  using  Intel's  SBC-86/30  single  board 
computer  having  a  8086  microprocessor . 
The  other  implementation  is  using  an  Irtel 
SBC-286/10  board  containing  a  80286  micro¬ 
processor.  The  fundamental  difference  is 
that  the  80286  microprocessor  implements 
in  hardware  the  following  functions: 
memory  management,  task  switching,  and  an 
interrupt  hardier.  The  8086  microproces¬ 
sor  implements  the  above  functions  by 
means  of  RMS-86  operating  system  software. 


The  specifications  for  the  benchmark 
are  as  follows:  (1)  8086  microprocessor 

Intel  286/287  operating  at  5  mhz,  (2)  program  and  data 
in  local  memory,  and  (3)  software 
161  uSec  functions  execution  times  are  linear  with 

311  uSec  respect  to  clock  speed.  As  indicated  in 

the  performance  ratio  column  of  Table  4, 
472  uSec  it  is  important  to  implement  as  much  as 

possible  all  operating  system  functions  in 
hardware  if  speed  is  important. 


OPERATING 

SYSTEM 

FUNCTION  »*  FUNCTION 
IMPLEMENTA¬ 
TION 

MICRO¬ 

PROCESSING 

CLOCK 

SPEED 

EXECUTION 

SPEED 

PERFORMANCE 
RATIO  » 

RMX-86 

SOFTWARE 

TASK 

SWITCHING 

8086 

5mhz 

1 . 2mSec 

1  .0 

RMX-86 

SOFTWARE 

TASK 

SWITCHING 

8086 

8mhz 

750uSec 

1  .6 

RMX-86 

SOFTWARE 

INTERRUPT 

LATENCY 

8086 

5mhz 

240uSec 

1  .0 

RMX-86 

SOFTWARE 

INTERRUPT 

LATENCY 

8086 

8mhz 

1 50uSec 

1.6 

RMX-86 

HARDWARE 

TASK 

SWITCHING 

80286 

lOmhz 

1 7uSec 

70 

RMX-86 

HARDWARE 

INTERRUPT 

80286 

10  mhz 

3uSec 

80 

*  Based  on  8086  Operating  at  5mh  Clock 
x**  Primary  Implementation 


PE  8/32D 

Floating  Point  20  uSec 
Table  Search  107  uSec 


Total  Time  127  uSec 

Table  3 


Operating  System  Benchmark. 
Table  4 


BUS  BANDWIDTH 


Distributed  microprocessor  bus 

performance  is  a  complex  subject.  The 
author  preserts  below  a  eoreise  outlire  of 
the  major  cor s iderat ior s  involved  ir  bus 
performarce . 

1.  Overhead  Ir  trod  uoed  by  System 

F  urct  iors .  The  ”  multitasking  JFd 

mul t  i  process irg  operatirg  systems  are  the 
major  cortributors  to  overhead  times.  The 
multitasking  operatirg  system  affects  the 
total  system  overhead  at  task  executior 
level;  that  is  for  task  switching 
interrupt  handling,  exception  handling, 
error  detection  and  correction,  and  data 
validation  functions.  The  component 
overhead  is  due  to  the  main  system  bus 
priority  and  bus  arbitration  control  hard¬ 
ware. 

The  multiprocessing  operating  system 
and  its  priority  level  and  bus  arbitration 
hardware  logic  affect  the  main  system  bus 
overhead.  The  effects  of  the  hardware 
overhead  only  become  a  serious  problem 
when  the  software  and  system  conf iguration 
cause  an  excessive  number  of  main  system 
bus  accesses.  This  occurs  when  the  design 
forces  a  large  number  of  small  data 
transfers  between  many  single  board 
computers  resident  on  the  main  system  bus, 
causing  the  overhead  factor  to  become 
critical . 

The  multiprocessor  system  overhead  is 
caused  by  main  system  bus  interprocessor 
message  transfers  and  system  calls.  If 
the  software  and  system  configuration 
design  create  the  requirement  for  a  large 
number  of  these  functions,  then  the  multi¬ 
processing  operation  system  overhead  also 
can  become  a  critical  factor. 

2.  Multibus  Interprocessor  Protocol 

(MIP) .  ~The  MIP  specifies  the  implementa¬ 
tion,  environment  and  form  of  the  multi¬ 
processor  operating  system  software  and 
main  system  bus  hardware.  The  MIP 
specifications  permit  intertask 

synchronization,  message,  and  data 
transfers  residing  on  different  single 
board  computers  as  easily  as  task 
switching  on  single  board  microcomputers. 
Communication  between  tasks  can  be  either 
tightly  or  loosely  coupled,  depending  upon 
the  application  requirements. 

Loosely  coupled  tasks  require  only 
single  messages  to  be  sent  to  the 
receiving  computer.  Tightly  coupled  tasks 
provide  synchronization  by  means  of 
handshaking . 


3*  Optimal  Considerations  for  Single 
System  Bus .  The  following  rules  are 
configuration  guidelines  to  aid  in 
determining  the  performance  level  of 
uistriouted  microprocessor  single  bus 
systems . 


Each  SBC  microcomputer  operates  as 
independently  as  possible  with  the  follow¬ 


ing  local  resources:  local  Jjl  i  mt-m.ry, 
local  KOM  memory  for  program  storage, 
local  I/O  system,  and  loco!  spec  i  :  i  ze  i 
funeions  such  as  floating  point. 

Main  system  bus  bandwidth  resources 
should  be  limited  when  possible  to 
l n ter processor  and  system  data  transfers 
and  message  communicat ions . 

When  a  single  task  is  partitioned 
among  multiple  SBC  ini  rocomputers, 
application  system  design  shoull  be 
directed  towards  total  system  performance 
causing  system  bus  bandwidth  resources 
minimization  and  microprocessor  efficiency 
maximization. 

System  bus  parallel  priority  scheme 
and  system  application  design  can  optimize 
system  performance. 

Data  transfers  when  possible  should 
be  medium  to  large  blocks. 

ATD  COMPUTATIONAL  PERFORMANCE  EXAMPLE 

This  section  of  the  paper  uses  the 
computational  characteristics  of  the  B52 
Aerial  Refueling  Part  Task  Trainer  (ARPTT) 
as  an  estimate  of  the  CSA/cmi  ARPTT 
computational  requirements. 

1.  B52  ARPTT  Data.  The  B52  ARPTT  was 
implemented  using  a  single  Perkin-Elmer 
8/32D  minicomputer  in  each  trainer.  From 
informal  data  used  to  track  the 
development  of  the  project  software,  Table 
5  was  derived.  This  table  presents  an 
estimate  of  computational  performance  at 
the  time  of  completion  of  system 
development.  The  table  lists  the  real 
time  functions  implemented  in  the 
B52  ARPTT,  the  memory  requirements  for 
data  used  by  each  function,  the  memory 
requirements  for  the  executable  instruc¬ 
tions  (code)  and  the  execution  times  on 
the  PE  8/32D. 

It  is  clear  by  examining  the  data 
i-riat  tne  I  l  l gn t/mo t ior  ard  the  visual 
display  furcticrs  drmirate  memory  ard 
timirg  utilization  for  this  ATD.  These 
furctiors  represert  over  50%  of  the 
util'izatior  of  memory  ard  executior  time. 

2.  Sample  Micro  Layout  for  B52  ARPTT. 
Table  6  shows  the  B52  ARPTT  real  time 
furctiors  distributed  over  a  total  of 
eight  sirgle  board  computers  (SBC)  each 
residirg  or  the  same  sirgle  mair  system 
bus.  Ir  this  example,  the  followirg 
assumptions  are  made. 

A.  The  ratio  of  the  PE  8/32D  mini¬ 
computer  to  the  Irtel  286/287  micropro¬ 
cessor  system  performarce  is  6  to  1  as 
irdicated  by  the  Whetstore  performarce 
compar i sor . 

B.  Sirgle  board  computer  utilization 
at  50%  or  less  was  a  desigr  goal  based  or 
the  urcertairty  ir  the  time  executior  ard 
bus  loads  ard  based  or  the  irexpers l veress 


REAL  TIME  MINICOMPUTER 

FUNCTIONS  INTERDATA  8/32D 


DATA  * 

CODE  * 

TIME  ** 

Supervisor 

780 

20 

6.2 

Instruction  Aids 

132 

1,872 

7.5 

Host  VDU. 

13,760 

9,960 

1  42 

Boom  Control 

1  ,408 

3,656 

17.6 

Visual 

984 

4,68  0 

30.4 

Hydraulics 

360 

1  ,920 

5.0 

Fuel 

3,320 

5,380 

49-3 

AFCS 

780 

3,000 

22.5 

Engines 

1  ,184 

1,460 

7.2 

FI  ight/Motion 

11,300 

9 ,600 

247.5 

Control  Loading 

1,140 

3,564 

23-7 

Sound 

688 

1  ,268 

6 . 7 

Test/Preflight 

424 

536 

1.0 

Cycle  Time  Check 

168 

478 

1.6 

Digital  Read  Out 

948 

4,288 

5.6 

Subroutine/ 

Libraries 

I OS/IOC 

2,024 

4,168 

23-0 

Global  Data 

Library 

VDU  Page 

Generator 

12,960 

21,136 

7.7 

TOTALS 

52. 4K 

77.  IK 

655.0 

*  Bytes 

**  Milliseconds/Second 


B-52  ARPTT 

Computational  Performance 
Table  8 


cf  the  processor  hardware. 

c-  The  flight/motior  task  is 
partitioned  equally  among  3ingle  board 
microcomputers  (SBC)  A,  B  ard  C,  assum¬ 
ing  no  transport  delays. 

D.  The  two  tasks  "Host  VDV"  and  "VDU 
page  generation"  betweer  SBC  D  and  E. 

E.  Task  partitioning  of  the  B52 
ARPTT  tasks  is  based  upon  execution 
times. 

Fewer  SBC  could  be  used  in  the  desigr 
(perhaps  five)  if  one  wished  to  increase 
the  risk  by  decreasing  the  execution 
margin;  however,  urless  the  number  of  ATDs 
being  purchased  is  large,  the  additional 
hardware  expense  is  easily  offset  by  the 
risk  reduction  in  the  software  desigr. 

To  estimate  the  bus  bandwidth  used  in 
this  example,  it  is  further  assumed  that 
all  data  for  each  function  (showr  on  Table 
5)  is  transferred  ir  block  form  over  the 
bus  durirg  each  cycle  of  execution  of  that 
function.  This  provides  the  bus 
utilization  for  application  data.  In 
addition  fifteen  system  calls  and  messages 
per  application  cycle  were  ircluded  to 

represent  operating  system  bus  overhead. 


This  estimate  is  based  on  one  call  per 
function  per  cycle  shown  in  Table  o.  Under 
these  assumptions  only  401  of  the  single 
bus  capacity  was  used. 

Again,  it  must  be  emphasized  that  the 
software  implementation  approach  affects 
these  margins  considerably. 

SPECIFICATION  CHANGES 

The  prime  item  development  specifica¬ 
tion  (PIDS)  for  the  C5A/CK1B  ARRPTT  was 
reviewed  for  changes  based  on  the  concepts 
of  distributed  microprocessor  systems. 
Four  categories  of  additions/changes  are 
suggested.  These  deal  with  board  level 
products,  margin  reassessment,  operating 
system  configuration,  and  the  support 
concept;  each  category  is  discussed  below. 

1.  Board  level  Commercial  Products . 
To  avoid  the  contractor  temptation  to 
construct  unnecessary  special  purpose 
microprocessor  configurations,  the 
distributed  micro  based  central 
computational  system  should  be  constructed 
of  commercially  available  (and  second 
sourced)  board  level  products.  Where  the 
cost  is  not  prohibitive,  as  few  different 
single  board  computer  (SBC)  types  should 
be  used  (as  practical),  leading  to  much 
board  level  commonality  even  at  the 
expense  of  some  performance  inefficiency. 
Commercially  availalble  and  compatible 
system  buses  should  also  be  used.  This 
will  lead  to  a  lower  parts  cost  and  tend 
to  curb  contractor  development  at  the 
piece  part  level. 

2.  Margin  Reassessment .  Timing, 
memory,  and  I/O  margins  were  cited  at 
25J  in  the  PLDS.  As  the  cost  of  computer 
hardware  drops,  it  makes  sense  to  require 
additional  margin  (perhaps  as  much  as  501) 
to  ease  the  development  and  support 
burden.  The  uniform  application  of  margin 
over  each  SBC  n ay  no  longer  be  reasonable 
since  certain  processors  may  exercise 
functions  known  not  to  expand  while  other 
processor  functions  may  see  all  the 
growth.  For  a  distributed  system  of  this 
nature  it  may  be  wiser  to  indicate  the 
margin  in  terms  of  functional  growth  if 
that  is  possible. 

If,  above  and  beyond  margin,  hardware 
add-on  capability  is  specified,  then  the 
acceptance  tests  should  include  tests  in 
the  expanded  hardware  mode. 

As  bus  layout  and  bandwidth  are 
important  system  throughput  parameters,  a 
"bus  bandwidth  burner"  analogous  to  the 
"time  burner"  is  recommended  for  the 
system.  This  would  permit  the  more 
precise  estimation  through  measurement  of 
the  actual  bandwidth  margins. 

3.  Oper a  t i ng  System  .  The  selection 
of  commercially  available  operating 
systems  should  be  specified,  but  the 
operating  system  will  require  configura¬ 
tion  for  not  only  the  nominal  hardware 
topology  but  also  for  various  growth 


B52  ARPTT  (8/32D) 
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SINGLE  BOARD  MICROCOMPUTER  ASSIGNMENT 


REAL  TIME 
FUNCTIONS 

EXECUTION 

TIMES 

M  SEC/SEC 

SBC 

DESTINATION 
ASSIGNMENT 
(INTEL  286-10) 

REAL  TIME 
FUNCTIONS 

EXECUTION 
TIMES  PER 
FUNCTION 

M  SEC/SEC 

TOTAL 

EXECUTION 

TIME 

M  SEC/SEC 

Flight/Motion 

247.5 

A 

FI  ight/Mot ion 

495.0 

50  0 .0 

RMX-86  O.S. 

5.0 

B 

FI  ight/Motion 

495.0 

500.0 

RMX-86  O.S. 

5.0 

C 

FI  ight/Motion 

4  95.0 

500.0 

RMX-86  O.S. 

5.0 

Host  VDU 

142.0 

D 

Host  VDU 

426.0 

4  31.0 

RMX-86  O.S. 

5.0 

VDU  Page 

7.7 

E 

VDU  Page 

426.0 

431.0 

Generation 

Generation 

RMX-36  O.S. 

5.0 

Visual 

80.4 

F 

Visual 

432.0 

530.6 

Engines 

7.2 

Engines 

43.2 

RMX-86  O.S. 

5.0 

Fuel 

49.3 

G 

Fuel 

295.8 

536.0 

AFCS 

22.5 

AFCS 

135.0 

Boom  Control 

17.6 

Boom  Control 

105.0 

RMX-86  O.S. 

5.0 

Supervisor 

6.2 

RMX-86  O.S. 

5.0 

Instruction  Aids 

7.5 

H 

Instruction  Aids 

37.2 

310.2 

Sound 

6.7 

Sound 

45.6 

Test  Preflight 

1.0 

Test  Preflight 

40.2 

Digital  Readout 

5.6 

Digital  Readout 

33.6 

IOS/IOC 

2.3 

IOS/IOC 

138.0 

Cycle  Time  Check 

1  .6 

Cycle  Time  Check 

9.6 

Microprocessor  Assignment  Example 
Table  6 


mode3.  Documentation  on  how  to 
reconfigure  the  operating  system  for  these 
growth  modes  should  be  procured. 

4.  Support  Concept.  The  support 
concept  implicrt  in  the  PIDS  is  one  of 
procurung  the  latest  computer  and 
operating  system  versions  and  continually 
accommodating  all  vendor  changes.  This 
may  prove  to  be  inappropriate  for 
distributed  micro  systems.  Spare  parts 
may  be  delivered  with  the  system. 
Freezing  the  hardware  configuration  and 
the  operating  system  for  a  period  of  time 
(i.e.  seven  to  ten  years)  followed  by  a 
complete  replacement  of  the  computational 
system  may  be  more  cost  effective.  This 
will  require  further  study. 
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ABSTRACT 

The  incessant  increase  in  computational  power  provided  by  microelectronics  has  not  begun 
to  be  matched  by  corresponding  improvements  in  software  productivity.  This  now  trite  obser¬ 
vation  has  especially  pernicious  implications  in  the  Weapon/Mission  simulator  field,  where 
massive  developments  of  demanding,  new,  real-time  software  in  relatively  short  time  spans 
are  a  way  of  life. 

This  paper  describes  a  new,  comprehensive  approach  to  satisfy  this  need:  a  software 
development  environment  which  relates  the  total  set  of  information  relevant  to  the  software 
product  through  data  base  management  techniques.  The  main  elements  of  the  concept  include: 

1)  Organization  of  the  simulator  (software  and  hardware)  into  a  hierarchical  frame¬ 
work,  clearly  separating  functions  so  that  top-down  design  and  modularization  will 
be  substantially  easier. 

2)  Arrangement  of  all  types  of  product  information  —  from  specifications,  through 
requirements  and  designs,  to  code  itself  --  in  an  engineering  data  base  patterned 
exactly  upon  the  hierarchical  framework  in  “1"  above. 

3)  Merging  of  management  status  information  and  configuration  control  data  into  the 
same  framework. 

4)  Provision  of  a  coherent  set  of  tools  to  "connect"  all  elements  of  the  data  base  for 
development,  control,  and  management  purposes. 

\ 

Progress  to  date  has  shown  that  explicit  correlation  among  all  elements  of  the  data  base 
can  exist  and  that  traceability  (location  and  identification)  of  each  functional  entity  is 
readily  provided.  Precise  configuration  is  known  at  each  level  of  development,  which  inher¬ 
ently  leads  to  configuration  management,  an  automatic  “coldstart"  capability,  and  correlation 
of  changes  to  related  information  sets. 

It  is  our  conviction,  based  on  experience,  that  the  creation  of  an  all-inclusive,  data- 
based  product  development  and  management  system  such  as  the  one  described  herein  is  essential 
to  cope  with  the  software  quality  and  schedule  needs  of  modern  Weapon/Mission  simulator  de¬ 
velopment  programs. 


BACKGROUND 

For  a  number  of  years,  the  frustration  asso¬ 
ciated  with  specifying,  managing,  developing, 
testing,  and  maintaining  complex  simulators  has 
tormented  both  customer  and  supplier.  The  In¬ 
dustry  has  witnessed  a  significant  growth  In  the 
development  of  training  devices  with  heavy  empha¬ 
sis  on  software.  Methodologies  and  tools  have 
been  generated  In  order  to  identify  and  correct 
problems  but  software  Induced  overruns  still 
occur  while  products  fall  short  of  their  goals. 

In  May  1980,  Dr.  Boehm  presented  the  accompany¬ 
ing  figure  (see  Figure  1)  depicting  the  cost 
trends  related  to  hardware  and  software. 

As  larger,  more  complex  programs  are  under¬ 
taken,  previous  tools  and  methodologies  no 
longer  are  adequate.  Added  to  the  complexity 
factor  Is  the  schedule  factor  which  has  remained 
unchanged  or  shortened.  The  sum  total  is  soft¬ 
ware  development  which  is  burdened  with  problems 
and  Issues  that  work  against  a  high  quality  end 
product. 


In  general,  the  errors  associated  with  these 
software  Intensive  devices  can  be  classified 
into  three  basic  areas:  requirement  errors, 
design  errors,  and  coding  errors.  Figure  2,  pre¬ 
sented  at  the  AIIE  1977  Software  Conference,  il¬ 
lustrates  the  dominant  type  of  error  as  program 
size  grows. 


The  software  development  problem  has  reached 
its  present  level  of  severity  largely  because  of 
the  use  of  manual,  or,  at  best,  semiautomatic 
means  originally  formulated  for  "average”  pro¬ 
grams.  On  today's  medium-  or  large-size  projects 
the  software  structure  and  all  of  the  data  asso¬ 
ciated  with  each  of  its  modules  cannot  be  re¬ 
corded  and  manipulated  manually  with  any  hope  of 
acconroodatlng,  In  real  time,  the  high  level  of 
change  activity  associated  with  the  software 
engineering  process.  Th.s  paper  describes  an 
approach  to  creating  an  orderly,  coherent  soft¬ 
ware  development  environment  for  simulator 
software. 
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Figure  1.  HARDWARE-SOFTWARE  COST  TRENDS 
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Figure  2.  POTENTIAL  DEFECTS  IN  PROGRAMMING 


APPROACH 

One  of  the  most  obvious  conclusions  that  can 
be  drawn  from  past  programs  Is  that  there  must 
be  an  effective  procedure  by  which  software 
development  for  a  simulator  can  be  broken  down 
Into  segments  which  can  be  effectively  managed, 
produced,  tested,  and  documented.  The  software 
engineering  process  itself  consists  of  many  Inte¬ 
grated,  creative,  and  procedural  tasks.  There¬ 
fore,  the  first  requirement  for  management  of  a 
large  software  enterprise  Is  that  It  be  broken 
down  Into  units  small  enough  to  be  effectively 
worked  on  Individually.  This  can  generally  be 
done  by  constructing  a  "software  family  tree" 
which,  at  a  minimum,  assigns  module  designations 
to  Identified  software  functions  that  must  be 
performed  for  the  proper  operation  of  a  simulator 
system  or  subsystem.  The  software  functions  must 
be  responsive  to  provisions  of  a  specification, 
a  functional  description  of  an  operational  unit, 
or  a  formal  statement  of  requirements.  Ironical¬ 
ly,  these  requirement -type  documents  themselves 
tend  not  to  follow  the  functional  breakdown  of 
the  software  family  tree,  since  they  were  pre¬ 
pared  completely  independently  of  the  functional 
structure.  Consequently,  multiple  cross-refer¬ 
encing  becomes  necessary  If  the  functional  soft¬ 
ware  modules  are  to  be  traceable  and  accountable 
to  a  customer-approved  or  customer-furnished 
standard. 


A  hierarchical  structure  for  partitioning  a 
simulator  into  functionally  meaningful  elements 
has  been  developed.  The  elements  were  selected 
so  as  to  maximize  internal  coherence  and  track  - 
ability  while  minimizing  harmful  interaction 
between  various  simulator  parts.  Each  major 
function  can  be  partitioned  hierarchically  until 
levels  are  reached  where  the  complexity  of  the 
elements  are  readily  manageable  by  an  individual 
with  a  single  work  assignment.  Partitioning 
rules  are  being  developed  to  ensure  that  the 
following  benefits  are  realized: 

1)  Well-defined  interfaces  will  exist  be¬ 
tween  elements  at  all  levels  of  the 
hierarchical  structure. 

2)  Progress  in  each  element  will  be  inde¬ 
pendent  of  all  others  as  long  as  inter¬ 
faces  have  been  defined  and  are  properly 
maintained. 

3)  Clearly  defined  element  responsibility 
will  be  established  v  thin  the 
hierarchy . 

4)  There  will  be  a  minimum  propagation  of 
disruption  to  other  parts  of  the  simu¬ 
lator  caused  by  requirement  changes, 
data  corrections,  limitations  on 
availability  of  manpower  assigned, 
quality  of  output,  etc.  The  extent  of 
this  propagation  will  be  evidenced  by 
reflecting  changes  in  the  established 
interface  conditions. 

5)  Documentation  will  have  a  one-to-one 
relationship  with  the  structured  par¬ 
titions  and,  therefore,  will  receive 
the  benefits  of  visibility  and  insen¬ 
sitivity  to  schedule  disruption  or 
change  activity  occurring  in  unrelated 
parts  of  the  simulator. 

Because  of  the  complex  nature  of  current 
simulators  and  the  real-time  requirement  changes 
that  go  on  during  the  life  span  (anywhere  from  3 
to  7  years)  of  a  contract,  an  automated  manage¬ 
ment  system  relating  all  of  the  data  Is  para¬ 
mount.  The  development  of  a  Software  Engineering 
Management  System  (SEMS),  which  Integrates,  with¬ 
in  a  single  common  data  base,  information  relat¬ 
ing  to  the  content  and  progress  of  the  elements 
In  the  hierarchy,  is  underway.  The  SEMS  is  the 
means  by  which  complete  information  regarding 
status,  content,  constraints,  and  interfacing 
will  be  assembled  and  maintained  within  a  common 
computer-based  environment  for  engineering, 
logistics,  and  management  purposes. 

A  major  requirement  of  the  data  base  philos¬ 
ophy  employed  in  this  development  was  that  each 
bit  of  Information  will  be  contained  within  the 
data  base  but  must  only  exist  once  within  the 
data  base.  This  key  factor  established  the  re¬ 
quirements  for  a  distributable,  relational  data 
base.  Since  there  are  a  relatively  large  number 
of  Data  Base  Management  Systems  (DBMS's)  avail¬ 
able,  the  following  major  criteria  were  used  to 
narrow  the  selection  process: 

-  Strong  support  for  unstructured  management 
inquiry  of  the  data  base. 

-  Minimum  load  on  the  resources  of  the  host 
computer. 
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-  Avoidance  of  heavy  commitment  to  a  partic¬ 
ular  computer  vendor's  product  line. 

These  factors  lead  to  the  conclusion  that  a 
back-end  processor  (data  base  machine)  which 
operated  within  the  definition  of  relational 
data  bases  and  which  could  be  interfaced  to  any 
of  the  more  commonly  used  simulator  computers 
(i.e.,  Perkin-Elmer,  SEL,  Harris,  Digital,  etc.) 
was  essential.  The  proof  of  this  hypothesis  is 
now  being  developed  on  a  Britton-Lee  IDM  500. 

With  the  proposed  use  of  a  back-end  proces¬ 
sor,  it  was  clear  that  the  main  operating  en¬ 
vironment  of  the  primary  processor  must  be 
flexible  and  rich  with  support  tools.  The  UNIX 
(licensed  by  Bell  Laboratories)  operating  envi¬ 
ronment  was  selected  for  three  primary  reasons: 

1)  UNIX  is  currently  hosted  on  all  mini/ 
super  mini -computers  presently  used  in 
flight  simulators,  plus  several  (IBM 
and  UNIVAC)  main-frame  computers,  as 
well  as  several  microcomputers.  As  a 
result,  a  broad  range  of  UNIX-based 
systems  exist  which  are  capable  of 
handling  a  variety  of  efforts,  from 
major  development  in-house  to  on-site 
software  maintenance. 

2)  UNIX  provides  a  stable  work  environment 
for  engineering,  logistics  support,  and 
project  management,  producing  a  develop¬ 
ment  process  which  is  done  in  a  similar 
manner  from  project  to  project.  This 

is  a  great  advantage  in  that  it  avoids 
retraining  costs,  redevelopment  of  the 
same  subsystems,  schedule  delays,  etc., 
while  providing  independence  from  ven¬ 
dor  computational  systems  (e.g.,  soft¬ 
ware  development  for  a  Vendor  A  based 
simulator  could  be  conducted  on  a 
Vendor  B  computer  or  any  desired  combi¬ 
nation). 

3)  UNIX  use  is  expanding  rapidly,  thus 
allowing  great  access  to  additional 
software  tools  developed  by  other  users 
which  may  have  applicability  to  our  own 
development  process. 

Initially,  the  SEMS  is  targeted  to  be  able 
to  provide  the  following  capabilities: 

1)  Requirements/specification  reference 

2)  Module  interface  information 

3)  Status  information  for  each  component 
of  software  design 

4)  Design  code  implementation 

5)  Software  change  tracking 

Figure  4  presents  the  general  software 
development  environment  which  is  made  possible 
through  the  UNIX  tools  and  utilities.  A  work 
center  can  be  located  at  any  number  of  sites  and 
remain  in  continuous  communication  through  the 
UNIX  network  capability.  It  has  been  proven 
that  each  of  the  sites  can  have  different  com¬ 
puter  vendor  equipment  and  still  be  a  fully 


compliant  network  work  center  providing  file 
transfers,  data  base  transactions,  and  project 
interaction. 

Figure  5  represents  the  distribution  of 
functions  of  a  typical  network  work  center. 

User  system  connections  are  through  a  front-end 
teleprocessor  referred  to  as  the  network  inter¬ 
face.  This  interface  also  services  all  work 
center-to-work  center  communications.  The  rich 
tool  set  available  in  the  UNIX  environment  pro¬ 
vides  a  sound  basis  to  meet  the  present  and 
future  needs.  The  data  base  machine,  augmented 
by  the  UNIX  file  structure,  serves  as  the  vehi¬ 
cle  for  data  base  management.  A  project  data 
base  housed  within  the  data  base  machine  will 
contain  all  necessary  intelligence  for  simulator 
load  build  and  software  test.  These  data  and 
directives  must  be  formulated  into  command/data 
sequences  acceptable  to  the  target  environment 
for  the  particular  project.  The  functional 
distribution  represented  by  Figure  5  provides 
for  the  inevitable  condition  when  the  target  or 
simulator  computational  system  is  of  a  different 
manufacturer  than  the  simulator  development 
system. 

The  software  test  capability  for  a  simulator 
will  be  hosted  on  a  computational  system  similar 
to  the  actual  systems  used  on  the  particular 
simulator.  The  testing  (modules,  module  groups) 
of  simulator  software  will  be  performed  by  this 
system.  The  activities  typical  of  the  test  sys¬ 
tem  will  be  compilation,  link/load,  program  vari¬ 
able  location  resolution,  test  program  operation, 
preparation  of  test  results  and  residency  for 
test  programs  and  data.  SEMS  will  provide  the 
vehicle  for  test  processing.  Test  results  will 
be  received  back  in  the  SEMS  environment.  Trans¬ 
mission  and  receipt  of  the  test-associated  data 
and  software  will  require  no  special  handling  by 
the  development  engineer.  The  fact  that  another 
computer  is  involved  will  be  transparent  to  the 
user.  Definition  of  the  SEMS-to-simulator  soft¬ 
ware  test  system  interface  will  require  the 
determination  of  appropriate  protocol,  a  de¬ 
tailed  list  of  the  data  items  and  commands  to 
properly  direct  the  operation  of  the  software 
test  facility  computer,  and  a  description  of 
test  results  returned. 

For  each  simulator  target  computational 
system,  an  interface  with  SEMS  must  be  devel¬ 
oped.  All  software,  data,  constructs,  and 
load-building  information  will  reside  in  the 
SEMS  environment  and  must  be  manipulated 
uniquely  for  each  different  target  to  achieve 
the  desired  operational  result.  A  key  principle 
of  software  configuration  management  is  satis¬ 
fied  by  controlling  all  materials  for  the 
product  in  one  place,  namely  the  SEMS  data 
base.  The  fact  that  the  final  product  is 
generated  from  this  controlled  environment 
ensures  predictable  product  content.  The  fact 
that  no  other  sources  of  input  to  the  final 
product  will  be  tolerated  guarantees  product 
configuration  integrity.  The  tasks  necessary 
for  implementation  are  to  define  a  protocol  for 
SEMS/target  communication  interface  and  to 
determine  the  data,  software  items,  and  direc¬ 
tives  necessary  for  successful  load  building  on 
the  simulator  computer. 
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PRESENT  STATUS 

A  UNIX  environment,  hosted  on  a  Perkin-Elmer 
3210  and  interfaced  with  a  Britton-Lee  1DM  500, 
is  installed  and  working.  The  system  has  an 
auto-dial /auto-answer  modem  hookup.  The  system 
has  conversed  with  UNIX  systems  hosted  on  SEL 
and  VAX  computers.  It  has  accomplished  file 
transfers  and  file  manipulations  on  other  UNIX 
systems  in  directed,  when  available,  and  as- 
required  modes. 

The  development  of  a  relational  data  base, 
cross-referencing  the  software  elements  of  a 
typical  simulator,  has  been  accomplished.  Addi¬ 
tionally,  documents  (not  code)  related  to  the 
software  elements  have  been  entered  into  the 
data  storage  of  the  UNIX  environment.  This  data 
has  then  been  manipulated,  both  intentionally 
and  unintentionally,  and  successfully  controlled 
within  the  UNIX  environment.  (In  fact,  the 
schedule  and  on-going  progress  of  this  develop¬ 
ment  program  is  contained  in  the  "experimental" 
environment. ) 

The  policies  and  procedures  for  system  imple¬ 
mentation  are  now  being  refined.  The  B-52  WST 
is  being  used  as  a  model  since  it  represents  one 
of  the  most  advanced,  complex  simulators  built 
to  date.  In  conjunction  with  the  procedures 
being  developed,  key  individuals  from  the 
engineering,  logistics,  and  program  management 
areas  are  providing  real-time  feedback  regarding 
present  experiences,  both  good  and  bad.  In  this 
manner,  the  development  project  is  exploiting 
both  earlier  and  current  experience.  It  is 
expected  that  this  project  will  be  an  evolution¬ 
ary  system  with  refinements  far  into  the  future. 

FUTURE  GOALS 

The  proof  of  this  software  development  envi¬ 
ronment  will  be  in  its  universal  application  to 
new  simulator  programs.  Since  all  new  programs 
tend  to  have  their  unique  requirements  and 
development  patterns,  the  true  worth  of  the  sys¬ 
tem  will  be  in  its  flexibility  for  growth.  The 
present  system  has  concentrated  on  the  "Product 
Baseline";  i.e.,  the  set  of  technical  documents 
and  software  that  defines  the  trainer  software  at 
the  end  of  the  product  phase  of  the  software  de¬ 
velopment.  Expansion  into  the  following  areas 
is  occurring: 

-  Software  Functional  Baseline  —  i.e.,  the 
set  of  technical  documentation  that  de¬ 
fines  trainer  software  at  the  end  of  the 
software  planning  phase. 


-  Software  Allocated  Baseline  --  i.e.,  the 
set  of  technical  documentation  that  de¬ 
fines  trainer  software  at  the  end  of  the 
analysis  phase  of  the  software  development. 

-  Software  Design  Baseline  --  i.e.,  the  set 
of  technical  documentation  and  software 
that  defines  the  trainer  software  at  the 
end  of  the  design  phase  of  software  devel¬ 
opment. 

-  Software  Operational  Baseline  --  i.e.,  the 
set  of  all  technical  documentation  and 
software  that  define  the  trainer  software 
at  the  point  of  release  to  the  Customer 
Configuration  Management  System. 

And  if  the  software  development  process  can 
be  captured  in  an  automated,  data  base  system 
with  the  visibility  and  control  which  is  the 
objective  here,  why  not  capture  the  entire 
simulator  project  on  such  a  system?  Many 
activities  now  under  way  are  proving  that  this 
concept  is  viable  and  desirable. 

CONCLUSION 

The  system  described  in  this  paper  is  pres¬ 
ently  under  development.  It  appears  to  have 
great  potential  and  even  greater  flexibility. 

As  was  noted,  the  policies  and  procedures  for 
implementation  will  have  a  profound  effect  on 
the  successful  implementation  of  the  system.  In 
the  end,  this  development  system  may  represent 
the  technical  feature  which  most  affects  simu¬ 
lator  programs  in  a  positive  manner  in  the  years 
to  come.  It  will  be  the  tool  used  by  both 
technical  and  management  personnel. 
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ABSTRACT 

Generation  and  support  of  documentation  accompanying  software  development  is  historically  a  low-efficiency,  high-cost 
undertaking,  Freguently  the  situation  arises  where  a  choice  must  be  made  to  fulfill  documentation  requirements  and  incur 
cost  and  schedule  overruns,  or  to  complete  the  software  product  in  a  reasonable  time  and  deliver  less  than  adequate 
documentation  The  primary  difficulties  are  efficient  generation,  quick  and  thorough  update,  and  document  correlation  on 
large  protects.  Automated  methods  can  alleviate  these  problems  by  (1)  application  of  word  processing  systems  to  the 
generation  and  editing  of  descriptive  text.  (2)  use  of  a  data  base  manager-type  control  of  system  interface  definition  and 
document  correlation,  (3)  use  of  pseudo-code  for  first-time  design  and  flowchart  generation,  and  (4)  the  use  of  special 
purpose  software  tools  to  perform  analysis  of  code  for  flowchart  and  module  interface  updating 


Documentation  of  software  can  be  performed  on  several  levels  of 
complexity.  The  lowest  level  is  perhaps  the  basic  user's  guide  that 
accompanies  small  software  items  or  those  packages  where  a 
detailed  knowledge  of  life  software  internals  is  unneeded  or 
undesirable.  This  guide  is  usjally  textual,  giving  only  installation  and 
usage  instructions.  A  higher  level  of  complexity  is  encountered  when 
system  descriptions  are  included,  as  may  be  the  case  with  a  vendor's 
operating  system.  The  user  in  these  cases  is  given  needed 
information  on  the  interplay  of  the  system's  elements  and  possibly  a 
fair  amount  of  detail  on  the  internal  workings  of  the  system  in  addition 
to  the  installation  and  usage  information.  Still  omitted  are  the  detailed 
design  information,  engineering  trade-offs,  and  associated 
background  information  on  philosophy,  methodology, -etc  .  that  must 
accompany  the  most  complex  level  of  documentation  -  that  given  to 
the  military  or  the  government  in  general.  Examples  are  compliance 
with  the  "Part  II  Specification'  called  out  by  USAF  Data  Item 
Descriptions  DI-E-3120B/M1  Computer  Program  Product 
Specifications,  and  the  DI-H-3277/M7  Training  Equipment  Computer 
Program  Documentation 

The  Part  II  Specification  includes  computer  program  descriptions, 
table  and  data  base  descriptions,  a  real-time  cross  reference, 
programmer's  notebooks,  time  and  memory  allocation  tracking  data,  a 
Computer  Program  System  (CPS)  guide,  and  of  course,  any 
associated  vendor  manuals.  The  general  contents  of  the  Part  II 
Specification  are  depicted  in  Figure  1 .  Of  the  documentation  items 
listed,  only  two  items  are  easily  supplied:  the  listings  and  vendor 
manuals. 
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Figure  1.  Part  II  Specification  Structure 

On  a  large  software  project,  the  effort  required  to  produce  this 
documentation  can  be  staggering  The  Boeing  Military  Airplane 
Company  (BMAC),  in  building  the  B-52/KC-135  Weapons  Systems 


Trainer  (WST)  prototypes  for  the  USAF.  produced  approximately 
1 ,000.000  lines  of  source  code  This  resulted  in  roughly  91 ,000  sheets 
of  non-listing  detailed  design  documentation  This  does  not  include 
the  amount  of  documentation  produced  in  the  generation  of  functional 
specifications,  implementation  specifications,  or  the  programmers 
notebooks,  CPS  guide,  and  other  items  of  the  Part  II  Spec 
Additionally,  there  were  in  excess  of  7.000  revisions  to  the  source 
parts  comprising  the  CPS.  Assuming  that  each  revision  and 
associated  document  release  required  the  modification  of  a  minimum 
of  three  sheets  (one  flowchart,  one  narrative,  and  one  revision  status 
sheet),  there  were  at  least  21,000  regenerated  documentation  sheets 
for  a  total  of  1 12,000  effective  non-listing  pages  of  design  documents 

Naturally,  there  are  impediments  to  the  completion  of  a  task  of  this 
magnitude.  One  of  the  problems  with  which  many  organizations  must 
deal  is  the  lack  of  sufficient  numbers  of  skilled  engineers  and 
programmers  to  perform  the  designing  and  coding  tasks  Engineering 
support  personnel  who  should  undertake  much  of  the  documentation 
task  are  therefore  frequently  utilized  to  perform  in  an  engineering  role 
This  places  a  greater  burden  of  document  generation  upon  the 
engineers  and  programmers  which  adds  to  the  schedule  impact 

The  major  issue  in  documenting  software,  even  with  an  abundance 
of  designers  and  support  personnel,  is  the  cost  A  reasonable  cost 
estimate  for  a  delivered  page  of  documentation  is  three  manhours 
<MFf).|,)  It  can  be  assumed  that  about  one  MH  for  one  round  of  editing 
and  revising  with  an  additional  0.5  MFI  for  typing'2’  are  embedded  in 
this  figure.  Each  additional  revision  of  a  page  can  then  be  estimated  at 
1 .5  MFI.  The  documentation  cost  of  a  WST-sized  project  could  then  be 
expected  to  be  304,500  MFI,  or  approximately  1.750  man  months 
(MM).  This  can  be  further  emphasized  by  noting  that  a  comparison  of 
document  generation  to  code  generation  shows  that  documentation 
accounts  directly  and  indirectly  for  about  60  percent  of  project  costs  as 
opposed  to  40  percent  of  project  costs  for  coding.131  Obviously, 
documentation  is  a  candidate  for  cost  reduction 

Flow  can  this  cost  be  reduced?  Perhaps  the  most  apparent  remedy 
is  the  application  of  word  processing  to  those  areas  of  the  documents 
that  are  texual.  In-house  BMAC  experience  with  word  processing 
indicates  that  savings  of  60-70  percent  are  possible  when  revision  and 
retyping  are  undertaken  through  word  processing  rather  than 
conventional  secretarial  methods.  The  7,000-plus  released  revisions 
on  WST  could  be  translated  to  an  expected  expenditure  of  31.500 
MFf.  A  60  percent  reduction  via  word  processing  brings  about  a 
possible  savings  of  18.900  MH.  If  the  cost  of  revising  a  document 
page  is  conservatively  set  at  one  MH,  the  savings  over  the  21.000 
revised  pages  is  still  12.600  MH.  Applying  these  possible  savings  to 
the  embedded  revision  in  the  three  MH  per  page  yields  a  modified 
page  cost  of  2.4  MH,  implying  a  savings  of  20  percent  over  the  basic 
cost  of  the  91.000  non-revision  sheets,  or  54.600  MH  (still  using  one 
MH  per  embedded  revision)  When  considered  together,  the 
reductions  amount  to  about  67.200  MH  or  22  percent  Of  course,  the 
major  benefit  of  this  type  of  reduction  is  not  that  the  job  could  be  done 
more  efficiently.  Rather,  a  less  ominous  spectre  of  the  documentation 
cost  would  allow  the  job  to  be  performed  in  the  first  place 

The  word  processor  would  be  the  mainstay  of  smaller  projects  and 
those  supplying  only  the  lower  levels  of  documentation  Indeed  for 
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the  large  project  generating  a  Part  II  Spec,  the  word  processor  can 
play  a  very  large  role,  particularly  in  supporting  the  CPS  guide  the 
programmer  s  notebooks,  and  the  modeling  and  narrative  sections  of 
the  computer  program  descriptions  Other  areas  are  better  served  in 
other  manners,  especially  the  module  design  flowcharts  interlace 
lists,  data  base  structure  and  memory  allocation,  and  the  real-time 
cross  reference.  Of  these,  the  most  extensive  and  time-consuming  in 
generation  are  the  flowcharts  and  the  interface  lists 

Flowcharting  an  as-built  piece  of  software  is  prone  to  similar 
problems  as  writing  the  narrative  text  -  adherence  to  drawing 
standards,  typing  comments  into  the  flow  elements,  analysis  ol  the 
code,  etc.  An  alternative  is  to  implement  an  automatic  flowcharting 
tool.  Without  the  specific  approval  of  the  procuring  agency  however 
this  is  proscribed  by  data  item  descriptions  such  as  the  DI-H-3277/M7 
Why  is  there  an  aversion  to  auto-flowchartmg7  The  usual  auto-flow 
tool  has  been  used  to  generate  what  amounts  to  an  additional  listing 
ot  the  code  which  fails  to  enhance  the  software  s  supportabiiity  The 
secondary  goal  ot  an  auto-flow  tool  then  should  be  lo  chart  the  design 
in  an  understandable  and  useful  form.  One  of  the  more  highly 
acclaimed  design  approaches  is  the  top-down  method,  where  the 
basic  programming  problem  is  iteratively  divided  into  subsets  ol  less 
general,  more  detailed  problems  that  can  eventually  be  easily  solved 
on  an  individual  basis.  Flowcharting  a  top-down  design  in  a  likewise 
manner  greatly  enhances  the  usefulness  of  the  documentation  and  its 
acceptability  to  the  user. 

BMAC  has  an  auto-flow  tool  in  the  final  stages  of  development,  the 
Document  Support  System  (DSS).  which  performs  the  flowchart 
generation  in  a  top-down  manner  thus  directly  reflecting  the  levels  of 
the  design  At  the  same  time,  the  source  code  image  is  separated  into 
design  levels  corresponding  to  the  generated  flowcharts  and 
formatted  to  reflect  the  logic  nesting  of  each  level  For  illustration,  a 
simple  two-design  level  program  has  been  generated  and  analyzed. 
Figure  2  shows  the  entire  source  image  listing  of  the  program  which 
has  been  written  for  a  Gould  SEL  32/55  using  a  subset  of 
S-FORTRAN  developed  by  Caine.  Farber  &  Gordon,  Inc 
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Figure  2.  Example  Program 

Separation  of  the  code  and  attendant  flowcharts  per  design  level  is 
depicted  in  Figures  3  through  7,  The  leading  block  of  code,  used  for 
variable  mnemonic  attribute  generalion.  common  area  references, 
and  data  initialization  has  been  set  aside  in  Figure  3  Figures  4  and  5 
represent  the  top  design  level  ot  executable  code  In  Figure  4.  code 
subsection  1.1  is  shown  with  a  replacement  statement  highlighted  by 
dashed  lines,  while  subsection  1  2  is  represented  only  by  a  comment 
This  makes  it  immediately  apparent  that  1  1  is  not  subdivided  into 
lower  design  levels,  while  1 .2  is  The  flowchart  of  Figure  5  shows  the 
logical  How  of  the  top  design  level  Branching  due  to  TRUE  or  FALSE 
states  of  the  decision  is  indicated  by  T  or  FF'  within  the  logic  paths 
leading  from  the  decision  block  Figures  6  and  7  show  the  second 
level  of  design  (code  subsection  1 .2)  pictured  with  the  corresponding 
comment  and  process  block  displayed  in  the  previous  design  level  to 
aid  in  identification  of  the  listing  and  flowchart  Those  separated 
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Figure  3.  Leading  Code  Block 
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Figure  4.  Top  Design  Level  Code 
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Figure  5.  Top  Design  Level  Flowchart 
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Figure  7.  Second  Design  Level  Flowchart 

As  evidenced.  DSS  can  be  used  for  analysis  and  documentation  of 
existing  code,  provided  certain  coding  standards  have  been  followed 
Additional  applications  are  the  generation  of  first-time  flowcharts  and 
the  update  of  documentation  per  changes  to  design  Module 
designers  generate  a  pseudo  code  of  comments  and  generic  logic 
structures,  then  use  DSS  to  construct  the  design's  flowchart.  This 
gives  excellent  visibility  to  the  design,  its  evolution,  and  its  adherence 
to  top-down  and  structured  techniques.  The  example  program  of 
Figure  2  is  in  much  the  same  format  as  would  be  generated  by  a 
designer  under  these  circumstances.  The  two  variables  L  and  I  have 
been  inserted  to  provide  proper  syntax  for  the  IF'  logic  structures,  and 
would  be  replaced  with  proper  mnemonics  as  they  are  defined. 

An  extremely  optimistic  expectation  for  the  cost  of  the  flowcharts 
and  design  level  listings  would  be  1/4  MH  per  sheet  The  amount  of 
time  required  to  generate  all  the  sheets  represented  by  Figures  3 
through  7  was  about  15  seconds,  or  1/4-minute  of  real-time,  leaving  a 
great  deal  of  spare  computer  time  within  the  15-second  span.  If  we 
assume  that  text  and  boilerplate'  comprise  about  one-half  of  each 
design  document's  non-listing  pages,  and  the  other  half  consists  of 
flowcharts  and  design-level  listings,  we  can  arrive  at  a  cost-savings 
estimate  for  combined  word  processing  and  auto-flowcharting 


Applying  the  22  percent  word  processing  savings  to  one-half  of  the 
original  304.500  MH  cost,  or  152  250  MH  yields  a  savings  of  33  830 
MH  If  we  then  assume  the  15-second  expenditure  for  generating  the 
analysis  of  the  example  program  applies  to  each  sheet  rathei  than  ail 
of  them,  then  each  sheet  costs  15/3600  MH  or  1/240  MH  Compared 
to  oui  conservative  1/4  MH  estimate  for  manual  generation  this 
represents  a  savings  of  over  98  percent  The  original  cost  ot  the 
56.000  flowchart  and  design  level  sheets  would  be  14  000  MH  at  the 
t/4  MH  rate  A  98  percent  reduction  would  be  13,720  MH  tor  a  total 
savings  of  47.550  MH  Applied  to  a  revised  original  cost  of  166  250 
MH  (allowing  1/4  MH  each  tor  the  flowcharts  and  design  level  lists 
assumed  to  comprise  one-halt  of  the  112.000  effective  pages)  the 
results  are  a  savings  ot  nearly  27  percent  Possibilities  ot  this  son 
especially  given  the  conservative  estimating  obviously  stan  to  bring 
high  quality  large  documentation  tasks  into  the  realm  of  feasibility 

Documentation  of  module  and  system  interfaces  in  a  large  system 
can  be  substantially  more  difficult  than  the  documentation  of  the 
designs,  given  that  many  ot  the  designs  must  be  analyzed  and 
correlated  to  give  proper  information  for  a  few  interfaces  This  of 
course,  should  then  be  accomplished  in  parallel  with  the  progression 
of  the  design  as  the  interfaces  evolve  A  prime  candidate  for  support 
of  this  would  be  a  Data  Base  Management  System  (DBMS)  which 
correlates  and  maintains  a  data  base  of  system  interfaces  For  this 
purpose,  BMAC  has  instituted  a  DBMS  with  the  MAXXIMUM  data 
base  manager  by  California  Software  Products.  Inc.,  as  its  nucleus 
This  DBMS  maintains  interlaces  which  are  implemented  through  the 
Gould  SEL  Datapool  common  memory  facility  and  creates  the 
mnemonic  dictionaries  used  to  link  software  load  modules  to  the 
appropriate  data  spaces  within  the  Datapool  In  addition  to  the 
variable  mnemonic,  recorded  data  include  variable  attributes,  dates  ot 
entry  to  the  system  and  modification,  logical  location  within  the 
appropriate  Datapool,  software  modules  using  the  variable,  and 
computers  where  using  modules  are  resident  This  obviously  eases 
the  pain  of  document  generation  as  a  great  deal  of  this  information 
can  be  gleaned  from  software  module  source  code  Others  such  as 
logical  location  within  the  Datapool.  can  be  generated  by  the  DBMS  in 
response  to  variable  attributes,  unless  constrained  by  operator  input 
An  example  of  documented  interface  variables  is  given  in  Figure  8 
Each  of  the  two  variable  data  entries  gives  the  basic  information 
stated  above  plus  other  pertinent  facts  such  as  the  trequency  at  which 
the  data  is  used  and  generated  Such  listings  can  be  easily  generated 
for  entire  Datapool  mnemonic  dictionaries,  or  subsets  thereof,  to 
document  tables  and  data  bases  according  to  the  requirements 
contained  within  the  Part  II  Spec 

The  individual  software  module  documentation  is  enhanced  by  the 
DBMS-produced  module  interface  listing,  shown  in  part  in  Figure  9 
The  module  in  question  is  shown  boxed  in  asterisks  on  the  left  with 
individual  interface  linkages  drawn  to  related  modules  shown  boxed 
on  the  right  portion  of  the  figure  Each  link  shows  the  variable 
mnemonic  for  the  data  space  that  it  represents  the  type  of  data  space 
(i.e  ,  integer  byte,  logical  byte,  etc  ),  the  data  space  array  size  and  the 
relative  flow  of  data  depicted  by  an  appropriately  oriented  caret 

Interface  documentation  on  the  pari  of  the  DBMS  is  top-down  in 
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Figure  9.  Inter-Module  Interfaces 

essence,  starling  with  the  contents  of  the  data  base  and  moving  down 
to  the  module  interface  level  On  the  other  hand.  OSS  has  an  interface 
documentation  capability  that  starts  with  the  module  internal 
Interfaces  and  moves  up  to  the  system  level  An  interface  analysis  of 
the  brief  example  program  is  shown  In  Figure  10  The  variable 
mnemonics  I.  K  and  L  are  shown  to  be  unique  to  the  module,  while 
L8PPHUGD  has  been  found  in  a  predesignated  common  memory 
data  base,  thus  allowing  OSS  to  obtain  array-size  information  and  the 
variable's  description  Mnemonic  I  is  shown  to  be  an  output  of  level 
1.0,  by  virtue  of  an  O  in  the  left  column  of  the  I/O  matrix  in  the  right 
portion  of  the  figure  The  right-hand  column  (for  level  1  2)  has  no 
entry,  indicating  the  I  is  not  used  on  the  second  design  level  DSS 
has  obviously  shown  us  that  the  module  is  suspect,  since  a  unique 
variable  is  generated  as  an  output  in  one  design  level,  but  is  never 
used  as  an  input  Similarly,  mnemonics  are  shown  to  be  inputs  by  the 
presence  of  an  I  in  the  design  level  column  of  the  matrix,  and 
mnemonics  both  used  and  generated  are  represented  with  a  B  As 
DSS  analyzes  modules,  external  interface  information  may  be 
retained  and  later  used  to  document  interfaces  between  modules 
within  a  system,  and  between  different  systems  of  multiple  modules 
This  difference  in  approach  between  the  DBMS  and  DSS  is 
summarized  in  Figure  1 1  The  redundant  aspect  of  system  interface 
documentation  makes  an  excellent  cross-check  mechanism,  and 
helps  to  ensure  data  base  and  interface  integrity 
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Figure  10.  Example  Program  Interfaces 


Figure  11.  DBMS/DSS  Perspectives 


As  with  DSS,  the  DBMS  process  has  the  added  benefit  that 
discrepancies  can  almost  always  be  detected  and  brought  to  light  as 
soon  as  the  offending  source  code  is  analyzed  and  its  interface 
expectations  are  compared  to  the  data  base  the  DBMS  produces  an 
output  that  documents  these  discrepancies,  as  depicted  in  Figure  12 
This  particular  example  indicates  that  the  module  R02BBA0U  has 
defined  several  mnemonics  to  be  in  a  common  memory  area,  but 
never  references  these  mnemonics  in  executable  code  Additionally, 
the  mnemonics  are  shown  not  to  exist  within  the  data  base  This  has 
probably  arisen  from  a  previous  deletion  of  the  mnemonics  from  the 
data  base  and  executable  code,  while  a  somewhat  careless  change 
implementation  has  allowed  the  common  definitions  to  remain  Two 
other  variables  are  shown  to  disagree  in  array  sizes  between  those 
expected  by  the  module  and  those  implemented  by  the  data  base 

While  cost  estimates  for  the  preparation  of  interface  documentation 
are  not  really  available,  it  should  be  apparent  that  the  process  is 
certainly  no  easier  than  manual  design  documenting  Suffice  it  to  say 
that  the  process  which  generated  the  information,  of  which  Figure  9  is 
a  part,  took  less  than  tour  minutes  of  computer  real-time  The 
possibilities  of  savings  should  speak  for  themselves 


In  order  to  efficiently  perform  these  flowcharting  and  interface 
documenting  capabilities,  some  standards  and  conventions  should  be 
imposed  upon  the  software  to  be  documented  In  the  instance  of  the 
interface  DBMS,  variable  mnemonics  are  required  to  utilize  the  first 
three  characters  to  show  variable  attributes  of  type  and  size,  and 
whether  they  are  to  reside  in  a  particular  region  of  the  Datapool 
common  area  or  are  unique  to  the  module  DSS  requires  that  the  code 
follow  structured  precepts  and  be  designed  in  a  top-down  fashion 
Submodules  and  design  levels  within  the  code  must  then  be 
commented  with  a  numbering  system  that  indicates  to  which 
submodule  and  design  level  a  segment  of  code  belongs  Figure  13 
illustrates  the  hierarchical  numbering  of  the  example  program 
processed  by  DSS  It  can  be  successfully  argued  that  other  benefits  of 
such  practices  (e  g  .  increased  reliability)  far  outweigh  the  trouble  of 
standards  implementation,  without  even  considering  the  applications 
to  documentation 

The  basic  requirements  of  a  general  Part  II  Spec  can  be  satisfied  with 
the  word  processing,  auto-flowcharting,  and  auto-interface- 
documenting  described  above  Other  items  such  as  the  Real-Time 
Cross  Reference  can  be  completed  with  an  extension  of  the  DBMS 
source  code  analysis.  Once  these  or  similar  mechanisms  are 
implemented,  however,  there  is  still  room  for  improvement 
Correlation  of  documentation  is  a  consideration,  as  are  consolidation 
of  document  integration  and  generation  of  such  items  as  test 
discrepancy  reports,  change  requests  etc  Document  correlation  may 
well  take  the  form  of  a  DBMS  function  that  maintains  data  on 
functional  requirements  documents,  implementation  requirements 
documents,  and  design  and  test  documents  A  change  to  a  functional 
requirement  paragraph  could  then  be  linked  to  subordinate 
implementation  requirements  and  design  and  test  documents, 
generating  a  need  to  change  list  Likewise,  a  module  design  change 
could  be  picked  up  by  the  DBMS  and  result  in  an  output  indicating  a 
need  to  change  the  appropriate  text  through  word  processing 


303 


If-Vlv'-C 


bi* 


l'«W  ?t.  /  |  <W  <  -  <1  :  1  1 


lUr1 


tt'-llHI'  1  > 


1  't  f  ",  I 


•  ••  —  -*^1  7  l 


r*»i‘S  -  v 


This  v  I  sru*J  (  *  ) 

VAPMHlf  IRpAOlMO 

i  riA.S  PWE 
SnOw*  HP 

V  I  o,,qL  T  ,  kfhlMM’ 

l  \  fiiMMU*  '•  L  i  f  »  /  f  X  1  F  N.H  1  • 

-t  N  P  t 

1  F  P-  ■  1,,*.  A  ►*  Ml  ? 

Is  1  f  * 

E 

Sf  ' 

H  » 

►  ’  id  v,*.  A  V 

V  AO  1  A  hi  E 

V  AQ I AHLfc 

1  MPAi.ll)  |  0 

I«PAO*»io 

•■'nfS  no! 

IIP 

APpf  AP  In  a  j  a  PASfc 

In  fO****uN  —  i  * :  r  «  / 

H.  W  1 

,  f  (•’  -  1  ,.  «•  A  M  Mill 

I  ^  Nf  V 

f  - 

SI 

M  t 

PM  ■  1-  -  A  V 

VAP I  A  RL  £ 
VA» l  A  ML  £ 

i  RP  At»>i?0 

I  MPAilllC^ 

m«Fs  n^T 

RnOwS  HP 

APpFAP  I\  ..*14  MAS  t 

IN  r0M*n..  MlCa  t  1  »l* 

«t  M.  w  J 

.  F  P  U  A  «  Mil 

I  *  ‘.h 

F » 

s  E 

M  1 

P  w  ■  . .  4  w 

V  AP I AHLf 

V  API  A  Hi  f 

I  OPAiillCO 

1 R$ innpQ 

''itfs  not 

ShO*$  ■  •*» 

APpf  iW  I*.  A  I  *  K/ct 

t  ^  fi  M-rv,  hi  "fx  /  t  *  I  E  ■*  1 

Mt  »■  P  Y 

if  PK.ll.W  A-  Mi  r 

I  \  F  V 

f  '• 

',t  • 

P„  i.MAM 

V  A  P I  A  ML  f 

V  A  P  I  A  ML  £ 
VAP I  AML  E 

I  «S  AuttpR 

1  R  S  a  T  r,  n 

LHPPCnpA 

ftof  s  nHT  A  pyt  J  *;  Al*  ■•ASf 

IN  S*  All  On  t**  -  A w  [  <  -  4  IT-  (  *4,  ■ 
»N  Mil  -  A**-AY  Mi<?MA|r*«  (Ml1 

■  L  t  = 
"If: 

n  (  i '  A  J  A  H  A  S  f  = 

\  )  (  ‘  A  I  A  hfttf: 

1 

i 

Figure  12.  Interlace  Discrepancies 


REFERENCES 

1  Boehm  B  W  Sottwate  Engineering  Economics  P'enlice 

Hall  1981  p  574 

2  ibid  p  572 

3  ibid  p  574 

ACKNOWLEDGEMENTS 

Special  thanks  to  Stan  Chiicotl  and  Jim  Richardson  of  Boeing 
Military  Airplane  Company  whose  programming  expertise  was 
indispensable 


Figure  13-  Example  Program  Design  Levels  and 
Submodules 

Document  integration  could  entail  consolidation  of  the  output  ot  these 
various  processes  in  order  to  avoid  the  manual  sorting  and  shuttling  of 
papers  Use  of  laser  printers,  plotters,  and  the  like  if  available,  is  not 
out  ot  the  question  With  the  obvious  savings  involved,  the  automatic 
processes  explored  can  make  giant  strides  toward  high-quality 
reasonably  priced  documentation 
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SOFTWARE  PROGRESS  TRACKING  SYSTEM 

T.  Michael  Moriarilv 
AAT  Corporation 
Cockevsvi l 1 e ,  Maryland 


ABSTRACT 


The  increasing  complexity  of  software  systems  combined  with  the  requirements  for 
structured  and  modular  designs  have  increased  many  fold  the  number  of  software  elements 
developed  and  delivered  on  recent  simulator  nrograms.  The  increased  number  of  elements  plus 
the  traditionally  "soft”  milestones  used  to  measure  progress  has  made  monitoring  software 
development  and  predicting  future  progress  time  consuming,  subjective,  and  often  unreliable, 

A  software  progress  tracking  system  which  uses  an  earned  point  scheme  has  been  success¬ 
fully  used  to  monitor  software  development  on  several  large  simulator  programs.  Points  are 
assigned  for  each  step  in  the  software  development  cvcle  on  a  per  element  basis.  The  steps 
are  "hard”  milestones  in  which  a  generated  product  is  accepted  bv  program  management.  As  the 
products  are  accepted  the  associated  points  are  earned.  The  ratio  of  earned  points  to  total 
possible  points  is  compiled  on  an  element,  functional  area,  or  total  software  system  basis  to 
determine  progress  achieved.  .A  report  generator  program,  usually  resident  on  the  simulator 
computational  system,  tabulates  the  data  in  a  variety  of  management  reports. 

The  system  as  implemented  is  flexible,  highly  automated,  and  is  closely  coupled  to 
configuration  management  systems  and  software  quality  assurance  procedures  to  ensure  validity 
if  data.  The  accumulated  point  values  are  quickly  ascertained,  objective,  and  based  or  the 
current  state  of  program  development.  Simple  calculations  or  comparisons  of  the  accumulated 
point  values  provide  an  accurate  measure  of  progress,  deviation  from  schedule,  and  prediction 
of  future  progress, 


INTRODUCTION 

A  large  body  of  literature  addresses  the 
functions  of  planning,  organizing  and  directing 
software  development  projects.  Many  texts  and 
articles  comprehensively  discuss  the  initial 
stages  of  a  project.  The  need  for  detailed 
requirement  specifications,  development  plans  and 
development  specifications  are  well  documented. 
The  Importance  of  clear  organizational  structure 
and  team  responsibilities  are  well  supported. 
The  techniques  of  top  down,  stepwise  refinement 
of  design  and  the  requirement  to  review  and 
validate  designs  early  in  a  program  are  well 
known.  Conscientious  application  of  these 
management  tools  help  ensure  that  the  completed 
software  product  will  meet  its  performance 
requirements  in  a  timely  manner. 

These  tools  and  techniques  emphasize  func¬ 
tions  performed  early  in  the  life  of  a  project. 
Less  information  is  available  on  the  on-going 
management  function  of  control.  Control  can  be 
thought  of  as  a  three  step  process:  an  attribute 
or  characterlst ic  of  interest  Is  measured,  the 
measured  value  is  compared  with  an  expected  or 
baseline  value,  and  an  appropriate  action  is 
taken  if  an  unacceptable  deviation  exists.  Any 
number  of  items  of  interest  during  software 
development  may  be  controlled  in  this  manner. 
Development  time,  development  costs,  computer 
memory  usage  and  computer  time  are  some  of  the 
more  common  items. 

The  purpose  of  this  paper  is  to  describe  a 
method  of  measuring  performance  of  the  software 
development  team  and  comparing  the  measured 
performance  to  a  baseline  schedule.  Performance 
here  refers  to  the  effectiveness  of  software 


development  personnel  in  meeting  established 
schedule  and  cost  targets.  Bv  providing  an 
objective,  timely  measure  of  actual  performance 
with  a  comparison  to  expected  performance,  proj¬ 
ect  management  will  have  the  means  to  pinpoint 
schedule  and  cost  deviations  thus  enabling  them 
to  take  action  to  assure  schedule  and  cost 
targets  are  met. 

A  performance  measurement  scheme  should  meet 
several  criteria.  First  and  most  importantly, 
the  scheme  should  be  objective.  The  person 
claiming  performance  should  not  be  required  to 
estimate  degree  of  completion.  Likewise,  the 
person  monitoring  performance  should  know  exactly 
what  a  performance  measurement  represents. 
Ideally,  the  state  of  development  should  be  suf¬ 
ficiently  visible  and  the  measurement  means 
sufficiently  clear  to  enable  any  project  member 
to  make  the  actual  measurement. 

Secondly,  the  scheme  should  measure  per¬ 
formance  in  accomplishing  the  real  task,  i.e., 
the  development  of  deliverable  software. 
Further,  the  resolution  of  the  measuring  scheme 
should  be  sufficiently  fine  to  measure  incre¬ 
mental  progress  on  a  weekly  or  monthly  basis  and 
the  measurement  should  be  timely  in  that  It 
measures  the  current  state  of  development. 
Providing  accurate,  current  performance  Infor¬ 
mation  on  a  periodic  basis  can  be  a  positive 
motivating  factor  for  a  programming  staff. 

Lastly,  the  scheme  needs  to  he  efficient.  It 
should  require  minimal  resources  to  collect, 
collate  and  report  performance  data  and  should 
require  minimum  time  to  interpret  the  results. 
Systems  which  require  constant  inputs  from  the 
programming  staff,  updates  by  clerical  personnel. 
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or  integration  of  large  amounts  of  data  bv  man¬ 
agement  are  not  used. 


TYPICAL  METHODS  OF  MEASURING  PERFORMANCE 

Performance  in  software  development  is  meas¬ 
ured  typically  either  by  estimating  percent  com¬ 
pleted  of  a  task  or  by  counting  the  number  of 
predetermined  milestones  which  have  been  reached. 
Tn  either  method  a  schedule  of  tasks  and/or  mile¬ 
stones  is  used  as  a  baseline  with  which  measured 
performance  is  compared. 

Tn  the  estimate  of  percent  completed  method 
the  person  actually  doing  the  work  estimates  the 
percent  of  the  work  which  has  been  accomplished 
in  reaching  a  milestone  or  completing  a  task. 
The  percent  completed  method  has  several  faults. 
The  malor  fault  is  that  the  measurement  is  sub¬ 
jective.  The  manager  is  asking  a  person  with  a 
vested  interest  in  completing  the  task  as  earlv 
as  possible  to  make  an  educated  guess  as  to  how 
nearly  complete  he  is.  Most  people  tend  to  he 
optimistic  in  their  ability  to  complete  a  task  - 
particularly  if  their  manager  subtly  encourages 
optimism.  The  old  bromide  of  a  task  being  9SZ 
complete  for  months  is  all  too  true. 

While  not  necessarily  a  characteristic  of  the 
percent  completed  method,  a  potential  shortcoming 
of  this  method  when  used  with  tasks  rather  than 
milestones,  is  the  definition  of  completion  is 
not  always  stated.  Therefore,  the  person  making 
the  estimate  may  have  one  perception  of  what  the 
task  includes,  while  his  manager  may  have 
another.  Hence  when  the  programmer  states  the 
task  is  100Z  complete  -  written,  tested  and  docu¬ 
mented  -  the  manager  may  have  an  unpleasant 
surprise  when  he  asks  to  see  the  Installation 
Guide.  Therefore,  since  the  end  of  the  task  may 
not  be  clearly  defined,  the  estimates  of  comple¬ 
tion  may  be  quite  inaccurate. 

Since  the  estimates  are  subjective,  the 
interpretation  of  the  results  may  also  he  sub¬ 
jective.  Tn  trying  to  ascertain  the  degree  of 
completeness  of  a  Job,  a  manager  may  ask  who  made 
the  estimate  and  then  apply  a  "correction  factor" 
to  the  estimate  for  that  person  to  get  a  number 
he  feels  comfortable  with. 

The  second  method,  or  milestone  method, 
attempts  to  alleviate  these  problems  by  defining 
specific  milestones  which  must  be  met  and  mea¬ 
suring  performance  by  summing  the  number  of 
milestones  which  have  been  met.  This  method  is 
much  more  objective,  tends  to  describe  the  over¬ 
all  task  more  fully  and  as  a  result  is  easier  to 
interpret.  The  shortcomings  of  this  method  are 
more  in  the  area  of  resolution  of  the  measurement 
versus  the  efficiency  of  collecting,  collating 
and  presenting  the  results  in  a  meaningful  way. 

In  order  to  get  the  resolution  of  measurement 
fine  enough  to  show  incremental  progress  on  a 
periodic  basis,  a  large  number  of  milestones  need 
to  be  defined.  However,  the  large  number  of 
milestones  makes  it  more  difficult  to  collect  and 
present  the  data  in  a  timely  and  meaningful  way. 
A  common  method  is  to  present  the  data  on  b^r 
graphs,  but  on  a  large  project  with  thousands  of 


milestones,  the  upkeep  of  bar  graph*,  ran  h»*  i 
slow,  expensive  effort. 

Another  potential  problem  is  that  tin*  mile 
stone  mav  not  accurately  reflect  the  real  task. 
If  care  is  not  taken  to  define  the  milestone,  the 
milestone  mav  not  he  based  on  deliverable  items 
hut  based  on  something  which  appears  to  show 
progress  such  as  lines  of  code  generated.  Also, 
if  the  milestones  are  not  carefully  chosen,  it 
mav  be  difficult  to  determine  ff  the  milestone 
has  been  reached. 


POINT  SYSTEM 

A  method  of  overcoming  these  problems  is  a 
point  system,  which  has  been  successfully  used  on 
several  large  simulator  programs.  The  point  sys¬ 
tem  is  really  an  extension  to  the  milestone 
system  which  lends  itself  to  automation.  in  its 
simplest  form  it  is  assumed  that  each  software 
module  goes  through  a  similar  development  process 
and  there  are  a  number  of  clearlv  identifiable 
milestones  within  that  process.  For  the  purpose 
of  illustration,  assume  ten  modules  will  he 
developed  and  four  milestones  will  define  the 
development  process.  The  milestones  may  repre¬ 
sent  design  reviewed  and  accepted,  code  walk¬ 
through  complete,  test  results  verified,  and 
module  released. 

Tn  the  simple  case  each  milestone  for  each 
software  item  is  worth  a  point.  Tn  the  case  of 
the  system  with  ten  modules  forty  (40)  points 
can  he  earned.  As  part  of  each  design  review, 
code  walkthrough,  test  verification  or  release 
audit,  the  milestone  is  achieved  and  the  corres¬ 
ponding  point  earned.  Ry  listing  all  of  the 
modules  and  milestones  achieved  (points  earned) 
in  a  computer  file,  and  creating  a  few  simple 
report  generators,  an  objective,  accurate,  and 
timely  measure  of  performance  can  he  acquired. 
Figure  1  shows  what  a  simple  status  report  might 
look  like. 


SOFTWARE  STATUS  REPORT 


DESIGN 


Module  A 
Module  B 
Module  C 
Module  D 
Module  E 
Module  F 
Module  G 
Module  H 
Module  T 
Module  J 

TOTALS 


CODE 

1 


TEST  RELEASE 


10 


1 


POINTS 

EARNED 

2 

1 

1 

1 

2 

\ 

2 

4 

1 

2 

19 


PERCENT  COMPLETE  =  19/40  =  48* 

Figure  1.  Simple  Status  Report 
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This  simplified  scheme  works  we  1 1  for  i  homo¬ 
geneous  sel  of  modules  where  3 1!  modules  .ire  of 
Ihe  same  complexity  and  each  of  the  milestones 
represent  an  approximately  equal  amount  of  work. 
Through  an  introduction  of  weighting  factors, 
modules  of  varying  complexity  or  milestones 
representing  unequal  effort  to  complete  can  he 
easily  handled. 

Before  this  and  other  extensions  are  dis¬ 
cussed,  however,  a  brief  description  of  imple¬ 
mentation  is  in  >rder .  The  heart  of  the  system 
is  a  computer  data  file  and  a  few  simple  report 
generators.  The  data  file  is  simply  a  collectioo 


of  records,  one  lor  each  item  which  is  f-  h- 
t  racked  ,  which  contains  fields  t  o  i  ml  i  .  .1 1  * 
whether  a  particular  milestone  has  been  me!  or 
not.  Usually,  It  is  advantageous  to  include 
fields  that  allow  for  description  of  the  item, 
responsible  analyst,  work  package  idenl i f i cat  i  on 
and  various  file  identification  fields.  Figure  1' 
shows  a  sample  record  layout.  C!ften  such  a  file 
will  serve  multiple  uses  particularly  it  a  few 
additional  fields  are  added.  Typical  uses  are 
Family  Tree  Definition,  Specification  Dross 
References,  Configuration  Control  l.ist.  Documen¬ 
tation  Cross  Reference,  and  anv  one  of  a  numher 
of  uses  where  a  comprehensive  list  of  deliverable 
software  Items  are  needed. 
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FILE  NAME 

SR  NAME 

RA 

WP  NUMBER 

TREE  DESiG 

DCTR 

DESCRIPTION 

_ 

_ 

_ 

_ 

_ 

File  Name  =  Name  of  File  as  It  exists  on  disk 
SR  Name  «  Name  of  Subroutine  as  It  Is  called 
RA  =  Responsible  analysts  Initials 

WP  Numher  =■  Work  Package  Number 
Tree  Deslg  «  Software  Family  Designation 

DCTR  -  Status  for  Design,  Code,  Test  and  Release  Milestones 


Sample 


FILE  NAME 

SR  NAME 

RA 

WP  NUMBER 

TREE  DESIG 

DCTR 

F.  UD 

>HEAD 
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:ad 
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I 

1A 

r 

1 

1 

It 

\20i 

biMi 

DESCRIPTION 

PR  INI 

Ht(A|D 

ik 

m 

JJ 

ST 

$ 

TT 

J_L 

! 

1 

r^s 

i  I  !  11 

Figure  2. 


Maintenance  or  updating  of  the  file  can  be  as 
straight  forward  as  modifying  records  with  a  line 
editor  or  as  complex  as  building  a  special  pur¬ 
pose,  Interactive  update  program.  Some  means  of 
limited  access  should  be  used  to  restrict 
unauthorized  modification  of  the  file,  parti¬ 
cularly  If  some  of  the  other  uses  of  the  file  are 
sensitive  to  change. 

Once  the  file  Is  updated  to  Include  an  entry 
of  the  module  under  development,  the  milestone 
status  fields  are  updated  as  the  milestones  are 


File  Layout 

met.  In  some  cases  this  may  be  a  manual  process, 
whereby  once  an  event  has  occurred  and  the  mile¬ 
stone  achieved,  a  program  librarian  or  other 
authorized  person  updates  the  status  file.  In 
other  Instances,  in  a  more  sophisticated  system, 
a  computer  program  could  determine  that  milestone 
event  has  occurred  (error  free  compilation  or 
successful  test  run)  and  automatically  update  the 
milestone  status. 

After  the  file  has  been  built,  report  gener¬ 
ator  programs  are  written  to  print  the  status. 
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For  sm.il  ler  projects,  a  program  which  simply 
prints  tMc'h  reroH,  suns  the  earned  and  points 
defined,  and  cal  dilates  the  percent  points 
earned,  mav  he  sufficient.  Larger  projects  mav 
need  several  reports  for  different  subsystems  or 
summary  reports  which  emphasize  change. 

F.XTFNSIONS 

A  number  of  extensions  can  he  added  to  the 
scheme  as  described  so  far.  The  first  is  to  add 
a  method  of  weighting  modules  and/or  milestones. 
While  weighting  all  modules  equally  on  a  large 
program,  where  manv  (over  I  MOM)  modules  exist 
appears  to  give  good  results,  smaller  programs 
with  few  modules  mav  need  to  weight  the  modules 
to  give  a  sufficiently  accurate  measurement  of 
performance.  Also,  depending  on  the  level  of 
visibility  of  the  measuring  system  and  the  atti¬ 
tude  of  the  personnel  involved,  there  mav  he  a 
tendency  to  do  all  the  "easv"  modules  first  to 
show  early  performance, 

A  similar  argument  can  he  made  for  weighting 
milestones.  Depending  on  the  acceptance  criteria 
to  meet  a  milestone,  some  milestones  mav  involve 
more  work  than  others,  therefore  achieving  those 
milestones  represents  accomplishing  a  greater 
amount  of  work  than  in  meeting  other  milestones. 
Further,  there  may  he  instances  where  a  combina¬ 
tion  of  module  weight  and  milestone  weight  may 
interact.  An  example  is  a  module  which  was  pre¬ 
viously  written  on  another  project  in  a  different 
language.  The  amount  of  design  work  for  that 
module  may  be  considerably  less  than  a  module 
designed  from  scratch,  but  amount  of  effort  to 
code  the  routine  might  he  more  since  an 
unfamiliar  language  may  be  involved. 

The  weighting  scheme  is  easily  implemented  by 
assigning  points  to  each  milestone  for  all 
modules.  Then  as  a  milestone  is  earned,  the 
assigned  points  are  added  to  the  totaled  earned 
and  divided  by  the  total  defined  points  to  com¬ 
pute  percent  completion.  The  number  of  points 
assigned  to  each  milestone  is  in  proportion  to 
the  difficulty  in  achieving  the  milestone,  and, 
in  fact,  relates  directly  to  the  estimated  number 
of  hours  needed  to  complete  the  milestone.  Tn 
assigning  points  it  is  recommended  that  points 
first  be  assigned  to  each  of  the  modules  and  then 
reapport ioned  to  the  milestones. 

A  second  extension  is  to  add  selecting  and 
sorting  options  to  the  report  generator  programs. 
Selecting  options  allow  the  user  to  select  all 
entries  in  the  file  by  some  field  such  as  work 
package  number,  file  name,  software  family  tree 
component,  or  responsible  analyst.  Once  the 
entries  of  interest  are  selected,  the  sort  option 
allows  the  user  to  order  the  entries  by  some  key. 
The  points  earned  and  points  defined  are  summed 
from  the  selected  entries  and  the  percent  com¬ 
plete  calculated.  Therefore,  reports  can  he 
printed  listing  all  modules  and  percent  complete 
for  a  certain  analyst,  work  package,  or  other 
selected  criteria.  Tt  has  been  found  valuable  to 
allow  boolean  operations  on  selection  fields 
(Analyst  A  AND  Subsystem  R)  and  to  provide  for 
major  and  minor  sort  fields  (List  modules  in 
alphabetic  order  by  analyst). 


A  •  bird  I'Xlt'Msj.H!  w1'  I  ■  I  h  IS  Is  !  , 

add  t  .  i  r  vT  t  dal***  and  ntu*!  ...mpl.-tion  daf*-s  f-. 
each  nodule  r»vnr-i.  In  this  .-x  l  **ns  i  ■  in  i  hr  i  nd  ’  - 
vidual  milestone  st  uns  fields  ar»*  replace. i  hv 
tv**  dates.  The  first  date  field  is  a  t  irgel  dale 
as  to  when  the  milestone  should  he  met.  The 
target  dates  do  not  have  to  he  used  for  all 
modules  or  milestones  hut  are  useful  where  an 
interdependency  exists  between  a  part  ini!  ir 
module  milestone  and  some  other  element  in  tie* 
svstem.  Those  interdependencies  n tv  exist  in  the 
design  stage  to  some  extent,  hut  they  become  very 
important  during  the  integration  phase  of  a 
pro  Ject . 

The  actual  completion  date  field  becomes  a 
flag  as  to  when  the  milestone  is  achieved.  Rv 
adding  un  the  points  assigned  to  a  milestone  that 
have  an  actual  date  entered  in  the  file  the  per¬ 
cent  complete  can  ho  computed. 

Using  the  two  date  fields  has  two  advantages: 
schedule  interdependence  can  he  monitored  and  a 
historical  record  exists  for  future  analysis.  Rv 
making  the  date  fields  selectable  and  sorlahle, 
additional  interesting  reports  can  he  generated. 
Assuming  that  an  integration  milestone  has  been 
identified,  a  list  of  all  modules  of  interest  can 
he  selected  by  WRS  work  package  number,  f ami  1 v 
tree  identification  or  individual  module  name. 
Target  dates  for  the  milestone  of  interest  can 
then  he  entered.  As  the  date  of  the  integration 
milestone  comes  closer,  lists  of  all  modules  of 
interest  which  have  a  particular  duo  date  and 
have  not  been  completed  can  he  provided  to  the 
responsible  analyst  or  work  package  manager. 
Judicious  use  of  these  lists  on  a  periodic  basis 
can  he  used  to  monitor  and  motivate  the  pro¬ 
gramming  staff  to  assure  the  milestone  is  met. 
Usually,  several  of  these  lists  in  various  stages 
are  active  at  once  as  kev  milestones  are  coming 
up.  It  has  been  found  that  choosing  approxi¬ 
mately  one  major  milestone  a  month  and  starting 
the  list  several  months  in  advance  of  the  target 
date  is  very  effective.  More  milestones  than 
this  tends  to  set  up  multiple  or  conflicting 
goals  for  the  individual  analysts.  Also  the 
lists  need  to  be  started  well  enough  in  advance 
to  allow  suitable  time  for  the  work  to  be  com¬ 
pleted  and  institute  work-arounds  if  problems 
arise. 

It  should  he  noted  that  the  meeting  of  these 
interdependency  dates  is  really  separate  from 
performance  measurement.  Tt  is  possible  that  in 
a  given  subsystem  the  performance  may  be  fully 
adequate,  say  75%  complete,  hut  a  key  integration 
event  may  have  been  missed.  The  manager  must  be 
aware  of  both  elements.  Tf  performance  is  where 
it  should  be,  but  an  integration  event  has  been 
missed,  it  may  mean  his  people  are  not  con¬ 
centrating  on  the  right  items  and  need  to  be 
re-di rected . 


ROLLING  BASELINE 

A  potential  problem  with  the  point  svstem 
described  thus  far  has  to  do  with  an  effect  known 
as  a  rolling  baseline.  The  rolling  baseline 
occurs  over  the  life  of  a  program  as  new  items 
are  continually  defined  and  added  to  the  status 
file.  This  has  the  effect  of  changing  the 
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are  met,  reported  progress  tends  to  flatten  out.  useful  i  n  crcal im:  inventory  lists  >t  sm|  iw in- 

In  some  instances  where  more  new  items  were  added  items  to  he  delivered  and  night  h,  -is- ■!  during, 

than  old  items  completed,  negative  progress  is  Physical  Configuration  Audits.  mi  h»-r  list*-  n  iv 

reported.  be  sorted  and-'or  selected  hy  w-r»  puk.tge  >  r 
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This  problem  is  overcome  bv  freezing  the  show  status  of  specific  modules  within  *.uhsets  of 
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once  a  package  of  work  is  defined,  no  new  points  responsible  analyst  shows  v t  n  ns  *t  a  p*rt  i«ut ar 

are  allocated  to  the  package.  If  for  some  reason  individual’s  effort.  Figures  *  and  ■*  show  i 

it  is  decided  certain  nodules  have  to  he  split  up  sample  detail  reports, 

for  sake  of  modularity  or  computing  efficiency, 

the  points  are  likewise  split  up  in  a  replanning  The  summary  reports  fund  ion  as  its  Mam- 

effort.  In  the  instances  where  the  scope  of  work  indicates.  They  sum  up  the  informal  ion  eener»t»*d 

changes  due  to  an  oversight  or  contract  change,  hv  the  detail  reports  md  simplv  total  the  items 

the  effort  is  reprogrammed  and  either  new  work  in  each  selected  category.  For  example,  a  detail 

packages  are  created  or  existing  work  packages  status  listing  of  all  elements  within  a  work 

are  expanded  with  a  corresponding  increase  of  package  can  generate  *  summary  that  indicates  tin- 

points.  total  number  of  elements  and  the  number  ot  ele¬ 

ments  that  have  net  each  milestone.  Kach  of  the 
This  has  the  effect  of  measuring  performance  milestones  (“an  also  he  expressed  as  a  percent, 

on  active  or  open  work  packages  nnlv  and  not  on  The  summary  reports  can  then  he  used  to  report 

the  svsten  as  a  whole.  However,  since  perform-  performance*  hv  whatever  category  is  needed,  i.e., 

ance  is  being  compared  to  an  established  schedule  work  package,  family  tree  element,  responsible 

which  is  also  made  tip  of  units  of  work,  the  analyst,  event  milestone,  etc.  Figures  S  and  h 

comparison  is  valid  and  useful.  show  sample  summary  reports. 

Collecting  data  from  several  summary  runs 
allow  rates  of  completion  to  he  calculated  upon 
which  trends  or  predictions  of  future  performance 
to  he  made. 
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SUMMARY 

The  point  system  for  performance  measurement 
during  software  development  provides  an 
objective,  ac evirate,  efficient  means  of  col¬ 
lecting  and  reporting  performance  data  in  an 
engineering  field  which  often  lacks  visibility. 
The  method  uses  data  which  is  based  on  deliver¬ 
able  software  items  and  which  is  collected  as  a 
normal  part  of  the  development  process.  The 
results  are  easily  interpreted  and  can  he 
presented  in  a  number  of  formats  and 
subdivisions.  The  scheme  is  flexible  and  can  be 
modified  to  meet  the  needs  of  projects  both  large 
and  small. 
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USER-FRIENDLY  SOFTWARE:  THE  ROLE  OF  THE  USER 
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This  paper  presents  a  definition  of  the  Urm  "user-friendly"  as  it  relates  to  computer 
software-human  interaction.  The  software  generation  process,  the  various  types  of  computer 
software  users,  and  the  role  users  should  play  in  the  software  generation  process  are 
described.  The  author  strongly  recommends  direct  involvement  on  the  part  of  the  user(s)  of 
computer  software  systems. 


INTRODUCTION 

Effective  and  efficient  system  operation  is 
a  function  of  good  communication  between  the 
various  parties  that  make  up  the  system.  Inter¬ 
faces  that  contribute  to  good  communication  be¬ 
tween  parties  should  be  the  goal  of  system  de¬ 
signers.  Poor  human-computer  interface  can  be 
the  result  of  inadequately  or  inappropriately 
addressing  user  friendliness  of  the  device  or 
the  system  equipment  during  design.  Many  sys¬ 
tems  currently  in  the  DoD  inventory  which  sup¬ 
port  weapon  systems,  simulators,  training  de¬ 
vices,  and  administrative  systems  have  computers 
at  their  foundations.  These  systems  have  direct 
human-computer  interface  requirements.  On-board 
computers  for  aviation  weapons  systems  are  com¬ 
mon  in  today’s  inventory.  Aircrew  members  oper¬ 
ate  computer-based  flight  systems  for  navigation 
and  fuel  management.  They  also  operate  mission- 
related  systems  that  are  partially  or  fully 
automated.  Most  modern  simulators,  trainers, 
and  training  devices  are  computer-driven  or  are 
in  someway  integrated  with  computer  technolgy. 
Even  electro-mechanical  maintenance  simulator 
devices  are  incorporating  a  computer  to  control 
system  operation,  student  performance  recording, 
and  other  training  requirements.  Several  auto¬ 
mated  administrative  and  management  information 
systems  exist  or  are  currently  being  developed. 
The  U.S.  Navy  has  automated  aviation  student 
records  in  the  ATSS,  and  is  in  the  process  of 
developing  a  system  to  support  undergraduate  jet 
pilot  training  student  performance  recordkeep¬ 
ing,  scheduling,  etc. 

Military  personnel  need  to  interface  with 
computers  directly  or  indirectly  on  a  day-to-day 
basis  at  all  levels.  Managers  and  administra¬ 
tors  receive  computer-generated  and  computer- 
formatted  outputs  which  they  must  analyze  and 
upon  which  they  make  critical  decisions.  Opera¬ 
tors  and  roaintainers  of  actual  equipment,  train¬ 
ing  devices,  and  administrative  tools  are  being 
introduced  to  computer-controlled  or  computer- 
integrated  systems  with  which  they  must  inter¬ 
face  to  successfully  accomplish  their  job. 
Therefore,  the  computer  systems  designed  for 
military  use  should  be  user-friendly  if  they  are 
to  be  readily  and  properly  adopted  by  the  mili¬ 
tary  personnel  who  must  operate  and  maintain 
them. 

In  general,  there  are  four  aspects  of  the 
human-computer  interface  that  are  related  to 
user-friendly  characteristics  of  a  system.  The 
four  aspects  are: 


1.  Hardwire  interface 

2.  Patterns  of  usage 

3.  Purpose(s)  of  the  system 

4.  Software  interface. 

The  hardware  interface  focuses  on  input  and 
output  devices  and  how  they  are  used  and  de¬ 
signed.  User  friendliness  is  typically  ad¬ 
dressed  through  the  hardware  interfaces  of  a 
system.  Computer  hardware  designers  have  re¬ 
placed  complex  keyboard  input  devices  with 
fingertip  control  trackballs  or  t ouch-sens i t i ve 
CRT  screens  and  have  reduced  human-computer 
interface  difficulties. 

The  pat terns-of-usage  aspect  of  user 
friendliness  relates  to  the  level  of  interac¬ 
tion,  direct  or  indirect,  between  the  user  and 
the  political  implications  of  the  human-computer 
interface.  System  patterns  of  usage  should  be 
based  upon  requirements  of  the  user.  Systems 
can  be  based  on  an  established  periodic  pattern 
of  usage,  a  constant  and  dynamic  pattern  of 
usage,  or  an  aperiodic  pattern  of  usage.  User 
friendliness  in  regard  to  patterns  of  usage  is 
dependent  upon  the  level  of  agreement  between 
the  user’s  equipment  and  the  pattern  established 
for  the  system. 

The  purpose(s)  of  the  system  involves  the 
intended  and  real  world  use  of  the  system  in  the 
environment.  The  purpose  of  a  flight  simulator 
is  inherently  twofold:  (1)  to  provide  an  envi¬ 
ronment  similar  to  actual  flight  experience  for 
training  and  proficient  skill  development,  and 
(2)  to  provide  a  means  to  safely  replicate  air¬ 
craft  disasters  and  emergency  situations  for 
analysis.  To  be  user-friendly,  the  mu  1 1 i leve led 
purposes  of  a  system  should  be  addressed. 

The  software  interface,  the  subject  of  this 
paper,  centers  around  the  design  and  use  of  the 
means  of  communication  between  the  user  and  the 
system  computer  program.  Software  engineers 
have  taken  a  more  critical  perspective  on  the 
degree  to  which  the  human-computer  software 
interface  is  user-friendly.  The  problem  of  poor 
software  interface  persists  because  the  software 
engineer's  perspective  represents  only  half  of 
the  relationship. 

What  a  software  engineer  or  designer  deems 
intuitively  obvious  from  his/her  perspective  is 
not  necessarily  based  on  a  common  frame  of 
reference  with  system  users.  The  vernacular  of 
software  engineers  and  designers  is  not  that  of 
the  user.  Instead  of  learning  to  use  or 


maintain  a  system,  the  operator  or  maintainer 
must  first  learn  to  think  like  a  software  engi¬ 
neer  or  designer.  This  situation  is  unsatisfac¬ 
tory  for  a  military,  or  for  that  matter  any, 
system  which  requires  a  human  interface.  The 
purpose  of  this  paper  is  threefold:  (1)  to  help 
define  what  user-friendly  software  should  be, 

(2)  to  identify  who  the  various  users  of  com¬ 
puter  software  are,  and  (3)  to  describe  the  role 
of  the  user  in  the  development  of  the  human- 
computer  interface  which  assists  the  user  to  do 
his/her  job  in  a  natural  way  that  is  easy  to 
understand  and  easy  to  use. 

DEFINITION 

What  does  the  term  user-friendly  mean? 

Some  would  claim  that  user-friendly  implies 
simplemindedness;  some  would  claim  that  it  means 
that  the  system  should  interact  on  a  personal 
level  with  the  user;  and  some  would  claim  that  a 
user-friendly  system  is  a  system  that  humans, 
rather  than  some  other  species,  can  operate. 

Each  of  these  definitions  is  inadequate.  It  is 
not  desirable  to  reduce  the  relationship  between 
man  and  computer  to  the  lowest  and  most  banal 
level  of  communication  to  achieve  user  friendli¬ 
ness.  Nor  is  it  necessary  for  a  computer  to 
communicate  with  humans  on  a  first  name  basis  or 
to  completely  simulate  human  interpersonal  be¬ 
havior.  Computers  have  inherent  and  man-made 
limitations  that  are  unavoidable.  The  user- 
friendly  system  capitalizes  on  system  inade¬ 
quacies  rather  than  highlighting  such  deficien¬ 
cies.  User  friendliness  is  more  than  providing 
for  any  human  interface;  it  is  the  capability  of 
the  system  to  interface  specifically  with  the 
level  and  type  of  user.  User  friendliness  is  a 
function  of  the  system  hardware,  software,  and 
human  interface  that  leads  to  increased  effec¬ 
tive  utilization  of  a  system. 

This  paper  is  concerned  with  computer  soft¬ 
ware,  particularly  training  and  training  equip¬ 
ment  related  software.  The  role  of  the  user 
should  be  investigated  in  relation  to  the  hard¬ 
ware  interface,  the  patterns  of  usage,  and  the 
purpose(s)  for  which  computers  are  used.  How¬ 
ever,  the  focus  of  this  paper  is  to  provide  in¬ 
formation  on  the  much  neglected  and  poorly  em¬ 
phasized  relationship  between  the  user  and  the 
computer  software  he/she  must  use.  The  follow¬ 
ing  list,  generated  from  literature  research  on 
user  friendliness  (reference  1-4),  provides  cri¬ 
teria  for  evaluation  of  the  level  of  user 
friendliness  of  computer  software: 

o  A  model  of  the  user 
o  A  discourse  language  which  is  com¬ 
fortable  for  the  user 
o  Responsiveness  to  user  vagueness, 
imprecision,  error,  and  status 
o  Level  of  effort  exerted  in 

performance  activity  results  in  a 
proportional  required  response 
o  Display  device  characteristics. 

User-friendly  computer  software  should  be 
based  upon  a  model  of  the  user  the  system  is 
designed  to  support.  A  maintenance  trainer 
should  contain  within  its  memory  the  fault  iso¬ 
lation  logic  that  an  expert  maintainer  would 


follow  to  fan  1 1 - i so  1  ate  a  problem.  For  novice 
pilots  the  scenarios  contained  in  flight  simula¬ 
tor  computers  should  be  primative  and  less  com¬ 
plex  than  the  scenarios  available  for  advanced 
pilots.  Computer-assisted  systems  should  have 
the  capability  to  monitor  student  performance 
and  respond  on  an  individual  basis  to  the  needs 
of  the  particular  student.  Without  the  thinking 
and  acting  processes  of  the  user  incorporated 
into  the  system  software,  a  disparity  will  ex¬ 
ist,  and  frustration  on  the  part  of  the  user 
will  be  increased.  The  flight  simulator  student 
comes  to  the  simulator  environment  with  a  set  of 
cues  and  responses  from  the  aircraft  that  he/she 
expects  to  have  replicated  in  the  simulator. 

The  degree  to  which  the  aircraft  world  and  the 
simulator  world  diverge  is  the  amount  of  nega¬ 
tive,  and  potentially  dangerous,  learning  that 
can  occur.  Training  time  is  negatively  af¬ 
fected,  and  frustration  due  to  the  student's 
need  to  eliminate  the  incongruencies  or  to  di¬ 
minish  their  effect  has  its  impact  on  learner 
mot ivat ion. 

A  user-friendly  computer  software  system 
should  communicate  with  the  user  in  the  common 
vernacular  of  that  user.  Language  aimed  at  one 
level  of  user  may  be  inappropriately  targeted 
for  users  at  a  different  level.  A  system  that 
places  a  burden  on  the  user  to  increase  human 
memory  requirements  to  understand  the  meaning  of 
the  language  being  used  offers  the  user  no  in¬ 
centive  to  efficiently  use  the  system.  It  may 
be  in  the  software  engineer's  common  parlance  to 
use  such  terms  as  DUMP,  EXIT,  bACK,  etc.,  but 
these  terms  are  not  typically  defined  in  the 
same  way  for  weapon  system  operators  or  main¬ 
tained.  Yet  one  finds  software  systems  direct¬ 
ing  operators  and  maintained  to  respond  to  such 
terminology.  Software  engineers,  like  the  mili¬ 
tary,  attempt  to  be  parsimonious  with  their  lan¬ 
guage  and  tend  to  abbreviate  words,  names,  and 
sentences.  Since  the  military  has  for  some  time 
been  the  leader  in  providing  the  English  lan¬ 
guage  with  acronyms  and  abbreviations,  is  it  not 
prudent  for  the  software  to  use  the  existing, 
yet  shorter,  vocabulary  of  its  user,  rather  than 
contributing  further  to  the  alphabet  soup  prob¬ 
lem?  The  amount  of  confusion  over  whose  defini¬ 
tion  is  appropriate  in  a  particular  case  could 
be  reduced. 

User-friendly  software  should  provide  a 
means  by  which  the  user  can  determine  what  has 
been  accomplished;  what  is  the  current  status  of 
the  interaction;  what  needs  to  be  done  to  re¬ 
cover  from  an  error,  a  miscalculation,  or  an 
imprecision;  and  how  to  maneuver  to  continue  to 
communicate  with  the  system.  The  user  needs  to 
know  what  has  transpired  to  a  given  point  in 
time  to  determine  what  response  is  required.  In 
order  to  determine  what  is  required  of  him/her, 
the  user  needs  to  know  whether  the  computer  is 
processing  a  response  or  expecting  a  response. 

It  is  necessary  to  embed  in  the  human-software 
interface  the  information  provided  in  human-to¬ 
ll  uman  interactions  that  defines  the  activity  and 
attention  levels  at  a  given  moment  in  time.  A 
very  annoying  characteristic  of  some  computer- 
assisted  instructional  (CAI)  software  is  that  no 
overt  indication  of  activity  or  attention  is 
indicated  on  the  output  display  device.  The 
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student  (unaware  that  the  computer  is  busily 
working  an  algorithm  or  processing  some  data) 
depresses  a  key  that  the  computer  interprets  as 
an  additional  request;  the  computer  thereby  ini¬ 
tiates  processing  on  a  redundant  task  or  marks 
the  student  wrong  for  not  following  a  procedure. 
A  simple  means  for  eliminating  unnecessary  pro¬ 
cessing  and  errors  of  this  type  is  to  provide  a 
clear  cue  to  the  student  that  the  system  is  re¬ 
sponding.  The  user  needs  to  have  a  means  to 
recover  from  errors  and  a  means  to  direct  recov¬ 
ery  efforts.  It  is  insufficient  to  merely  sup¬ 
ply  a  means  to  erase  an  input  or  change  a  value; 
the  user  needs  to  know  how  to  proceed,  or  the 
means  to  correct  errors  should  be  obvious  to  the 
user.  Performance  interruption  or  recovery  in  a 
simulator  is  principally  the  task  of  the  in¬ 
structor;  however,  this  is  not  the  case  with 
trainers  and  CAI  devices.  The  computer  in  a 
part-task  trainer  or  a  CAI  system  frequently 
takes  on  the  role  of  the  instructor  and  must  be 
able  to  assist  the  student  in  the  event  of  stu¬ 
dent  error.  Otherwise,  the  student  could  be 
lost  in  limbo  for  considerable  time  periods. 

This  does  not  imply  that  the  student  be  coddled 
through  procedures  when  he/she  errs.  Rather  the 
student  should  be  informed  of  what  the  system 
requires  to  continue  the  training,  particularly 
since  the  trainer  may  require  specific  actions 
that  are  not  the  same  actions  required  to 
recover  from  a  similar  situation  with  the  actual 
equipment.  For  example,  when  configuring  a 
radar  system  cor  operation,  there  is  typically  a 
minimum  warm-up  time  reqjired  with  the  actual 
equipment.  The  trainer  probably  would  not  re¬ 
quire  the  warm-up  time  since  it  would  be  ineffi¬ 
cient  in  part-task  training;  however,  the  stu¬ 
dent  would  need  to  step  through  some  mini¬ 
procedure  after  committing  an  error  that  would 
indicate  to  the  computer  that  the  warm-up  period 
requirement  had  been  met.  This  would  allow  the 
student  to  continue  without  receiving  warnings 
or  alerts  that  the  warra-up  time  was  not  met. 

Some  means  by  which  the  user  can  elicit  informa¬ 
tion  from  the  system  when  the  user  in  unsure  of 
how  to  accomplish  an  objective  should  be 
directly  accessible.  Prompts  and  cues  are  often 
used  in  software  programs  to  assist  the  user  in 
following  the  procedure  or  logic  pattern  and  to 
thereby  provide  a  means  by  which  the  user  can 
clarify  what  is  required  to  proceed.  Help  func¬ 
tions  should  be  available  upon  user  request  to 
meet  anticipated  user  problems.  The  following 
are  examples  of  cues,  prompts,  and  helps. 

o  Cues  and  Prompts: 

*  Press  NEXT  to  continue 

*  Answer  the  question  with  an  A,  B 
or  C 

*  Press  HOOK  VERIFY 

*  To  begin  another  scenario  press 
START. 

o  Helps: 

*  The  terra  Help  means  to  provide 
the  learner  with  assistance  upon 
request . 

*  The  critical  attribute  is  color 

*  The  proper  indication  should  be 
350  psi. 

A  user-friendly  computer  software  system 
should  follow  the  axiom  that  the  level  of  effort 


required  by  the  user  to  accomplish  the  objective 
of  the  interaction  is  proportional  to  the  re¬ 
sponse.  If  the  user  has  to  exert  more  effort  to 
ask  the  computer  for  the  time  of  day  than  it 
would  take  to  look  at  a  watch,  the  interaction 
process  is  inefficient  and  will  most  likely  not 
occur.  The  U.S.  Navy  found  that  the  instructor 
stations  for  highly  complex  and  integrated 
weapon  system  trainers  required  quick  and  ready 
access  to  scenario  modifiers.  The  instructor 
for  the  S3A  weapon  system  trainer,  for  example, 
needed  quicker  access  to  target  data  in  order  to 
modify  course,  speed,  and  location  during  stu¬ 
dent  prosecution  of  the  target  than  the  original 
simulator  software  provided.  A  menu-driven  tar¬ 
get  data  access  program  was  designed  to  provide 
more  immediate  access  to  modify  the  target’s 
data  base;  the  instructor  was  thereby  provided 
with  greater  control  over  the  evolving  training 
situation. 

In  summary,  to  achieve  user-friendly  soft¬ 
ware,  designers  and  users  must  work  together  on 
multifaceted  levels.  The  software  should  accom¬ 
modate  who  the  user  is,  how  he/she  is  to  inter¬ 
act  with  the  system,  what  peculiar  or  unique 
requirements  he/she  has  in  relation  to  the  sys¬ 
tem,  and  the  benefit  gained  by  the  user  from  the 
human-computer  software  interface.  All  rela¬ 
tionships  fit  a  cost-benefit  equation.  If  the 
cost,  in  effort,  time,  or  anxiety,  exceeds  the 
benefit  of  using  a  system,  the  possibility  of 
effective  and  efficient  system  utilization  is 
diminished. 

SOFTWARE  GENERATION  PROCESS 

Computer  software  program  development  is 
typically,  and  most  efficiently,  conducted 
through  a  systematic  process.  The  user  should 
have  knowledge  and  an  understanding  of  the  soft¬ 
ware  development  process  to  comprehend  his/her 
role  and  to  appreciate  the  job  of  the  software 
engineer.  The  closer  the  user’s  frame  of  refer¬ 
ence  is  to  that  of  the  software  engineer's,  and 
vice  versa,  the  more  friendly  the  system  inter¬ 
face  should  be. 

Software  generation  typically  follows  a 
seven-stage  process.  Stage  1,  planning,  in¬ 
volves  the  determination  of  system  requirements 
and  the  preparation  of  software  development, 
quality  assurance,  and  configuration  management 
plans.  The  product  of  the  planning  stage  de¬ 
fines  the  problem  and  the  expected/anticipated 
means  to  attain  usable  software  at  all  user 
levels  of  the  system.  Stage  2,  analysis,  in¬ 
volves  preliminary  designing  efforts  for  the 
system,  program  performance  specification,  and 
software  test  plans.  During  this  stage  the  end- 
product  software  is  specified  at  a  very  general 
and  functional  level.  Stage  3,  design,  involves 
program  design  spec i f icat ion,  software  module  or 
data  base  specification,  and  software  test  pro¬ 
cedures.  During  this  stage  the  software  design 
is  further  refined,  and  a  more  detailed  perfor¬ 
mance  specification  is  developed.  At  this  point 
in  the  process,  no  actual  coding  or  programming 
has  occurred.  The  products  to  this  point  are 
documents  providing  information  for  user  and 
developer  review  to  ensure  that  the  design  meets 
the  requirements  of  the  system.  Stage  4 , 
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production  and  test,  involves  the  coding  effort 
for  the  individual  software  modules  or  units  and 
the  verification  that  each  does  what  it  was  de¬ 
signed  to  do.  Software  to  support  a  system  is 
typically  subdivided  into  several  distinct  and 
testable  units,  each  of  which  is  first  debugged 
independent  of  the  others  to  reduce  trouble¬ 
shooting  when  all  units  are  integrated  and 
tested  during  Stage  5.  Stage  5,  integration, 
involves  a  total  system  test  on  the  functional 
configuration  of  the  system.  That  is,  unlike 
the  tests  conducted  during  Stage  4,  the  tests 
and  operation  conducted  during  Stage  5  must  sim¬ 
ulate  or  closely  resemble  the  system's  actual 
environment.  Stage  6,  acceptance,  involves  ac¬ 
ceptance  testing  of  the  system,  including  all 
software,  support  pub lications,  and  operating 
procedures.  During  this  stage  the  adequacy  of 
the  software  to  meet  the  stated  requirements  of 
the  system  must  be  determined.  Stage  7,  support 
and  control,  involves  the  continued  software 
support  required  to  modify  and  update  the  system 
software  for  the  life  of  the  system.  This  stage 
covers  change  procedures;  it  covers  the  means  to 
identify  software,  documentation,  design,  or 
logic  inconsistencies;  and  it  covers  the  means 
to  manage  the  configuration  of  the  system 
software  and  support  documentation.  The  typical 
path  through  the  software  generation  process  is 
not  a  smooth  or  straight-through  stepwise 
advance.  Several  interactions  within  steps  and 
revisiting  of  prior  steps  are  often  required 
before  all  parties  involved  can  and  will  sign- 
off  on  progress  throughout  the  generation  of  the 
software.  For  example,  the  impact  of  decisions 
arrived  at  during  the  design  of  the  software  may 
alter  the  software  development  plan  established 
during  Stage  1,  planning.  Before  actually 
committing  to  production,  the  software  engineers 
and  planners  will  revisit  the  development  plan 
and  ensure  that  the  software  generation  process 
does  not  lack  continuity.  In  another  case 
simultaneous  efforts  within  a  specific  step, 
such  as  the  development  of  operator  manuals  and 
the  final  acceptance  testing  results,  feed  one 
to  the  other  and  require  continuous  interchange 
to  ensure  valid  end  products. 

This  seven-step  software  generation  and 
follow-on  process  ensures  a  controlled  and  sys¬ 
tematic  process  to  oversee  the  software  develop¬ 
ment.  The  user  has  a  significant  role  in  this 
process  from  assisting  in  planning  to  providing 
inputs  for  engineering  changes  to  existing  soft- 


TYPES  OF  USERS 

There  are  basically  three  types  or  levels 
of  users:  end  users,  intermediaries,  and  pro¬ 
grammers.  End  users  are  those  humans  who  inter¬ 
face  with  the  computer  at  the  data  manipulation 
and  presentation  levels.  Intermediar ies  are 
those  humans  who  interface  with  the  computer  at 
the  intermediate  level  of  input  and  output.  In¬ 
termediaries  are  involved  in  physically  affect¬ 
ing  the  arrangement  of  data  and  data  files  via 
input  and  output  devices.  Programmers  are  those 
humans  who  interface  with  the  computer  at  the 
most  complex  level  of  input  and  output.  Pro¬ 
grammers  write  software  code  to  control  the 
means  by  which  intermediaries  enter,  exit,  and 


move  within  confined  areas  of  the  computer  mem¬ 
ory.  The  programmer  also  provides  control  for 
the  highest  level  input  and  output  for  the  end 
user.  Frequently,  one  individual  may  simultane¬ 
ously,  or  in  a  series  of  events,  interface  with 
a  computer  at  various  user  levels. 
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End  users  can  be  students,  managers,  admin¬ 
istrators,  letter  writers,  or  data  analysts. 
Intermediaries  can  be  instructors,  word  proces¬ 
sors,  data  processors,  terminal  operators,  or 
weapon  system  operators.  Programmers  can  be 
very  high  level  software  language  coders,  CAI 
developers,  or  machine  language  coders. 

ROLE  OF  THE  USER 

The  level  of  attention  that  is  focused  on 
the  process  of  eliciting  and  incorporating  user 
requirements  into  the  specification,  and  ulti¬ 
mately  into  the  implemented  system,  is  a  direct 
correlation  with  the  degree  to  which  the  system 
is  user-friendly.  The  user  has  a  critical  re¬ 
sponsibility  to  engage  in  interaction  with  the 
software  engineers  as  early  in  the  process  as 
possible.  The  user  should  provide  inputs  to  the 
process  from  the  planning  stage  through  to  ulti¬ 
mate  long-term  support  of  the  system.  Software 
generation  is  a  cumulative  process,  that  is, 
latter  stages  rely  on  assumptions  and  con¬ 
straints  underlying  the  products  that  preceded 
them.  Each  stage  uses  the  previous  stage  as  a 
starting  point  and  should  user  inputs  and  in¬ 
volvement  be  overlooked  or  ignored  during  early 
stages,  significant  impacts  to  system  design  at 
implementation  may  result.  Meeting  user  re¬ 
quirements  should  be  an  essential  part  of  deter¬ 
mining  the  overall  system  requirements.  The 
user  needs  to  assist  at  the  inception  of  the 
software  generation  process  to  outline  the  ac¬ 
tivities  he/she  is  capable  of  participating  in 
in  support  of  software  generation. 

In  two  aviation  system  procurements,  the 
VTX  and  the  E-6A,  the  U.S.  Navy  is  involved  in 
the  development  of  computer  software  to  support 
emerging  aircraft  systems.  The  VTX  program  is  a 
procurement  to  support  naval  undergraduate  jet 
pilot  training.  The  VTX  training  system  is  com¬ 
prised  of  four  major  elements:  the  T45  air¬ 
craft;  the  simulator  suite  of  an  operational 
flight  trainer  (OFT)  and  an  instrument  ilight 
trainer  (IFT);  an  academics  system  relying  heav¬ 
ily  on  computer-assisted  instruction  (CAI);  and 
a  recordkeeping,  student  tracking,  and  resource 
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scheduling  system  called  a  training  integration 
system  (TIS).  The  E-6A  program  is  a  procurement 
to  support  Take  Charge  and  Move  Out  (T AC AMO) 
operational  commitments.  The  E-bA  has  a  train¬ 
ing  requirement  for  a  crew  and  maintenance  per¬ 
sonnel.  The  program  currently  calls  for  the 
procurement  of  E-6A  aircraft,  a  flight  simulator 
specification,  and  front-end  analyses  to  estab¬ 
lish  specific  training  requirements. 

NAVAI RSYSCOM,  the  U.S.  Navy's  Aviation  Systems 
Command  and  the  procuring  agency  of  these  emerg¬ 
ing  systems,  has  considerable  experience  in 
working  with  the  software  generation  process  as 
it  relates  to  training  and  training  equipment. 
Their  experience  has  led  them  to  work  with  their 
sponsor  in  the  development  of  Fleet  Project 
Teams  and  Special  Program  Offices  to  provide  di¬ 
rect  input  into  the  system  from  the  user  com¬ 
munities.  The  U.S.  Navy  also  was  involved  in 
the  development  of  computer  software  to  support 
the  S-3A  training-related  data  base  system.  The 
S-3A  is  an  anti-submarine  warfare  (ASW)  air¬ 
craft,  which  the  Navy  felt  needed  a  front-end 
analysis  update  to  support  their  fleet  readiness 
squadron  (FRS)  training  system.  The  front-end 
analysis  data  was  generated  in  an  electronic 
format  and  controlled  through  computer  software. 
The  user  community  was  invited  to  participate 
throughout  the  system  development;  however,  the 
invitation  was  informal,  and  the  program  suf¬ 
fered  due  to  a  lack  of  experience  in  handling 
user  inputs.  This  section  of  the  paper  will 
describe  the  role  of  the  user  during  each  stage 
of  the  software  generation  process,  and  will 
refer  to  the  NAVAIR  experiences  to  provide  les¬ 
sons  learned. 

User  inputs  during  the  planning  stage  with 
regard  to  user  requirements,  to  user  resource 
allocation  for  product  review  and  in-process 
review,  and  to  other  planning  concerns  are  inte¬ 
gral  to  ensuring  that  end-product  software  is 
user-friendly.  Users  should  ensure  that  they 
are  to  be  involved  throughout  the  software  gene¬ 
ration  process,  and  that  their  level  and  degree 
of  involvement  is  explicitly  stated  in  planning 
decisions  and  documentation.  The  user  should 
ensure  that  adequate  time,  resources,  and  occa¬ 
sions  for  review  and  acceptance  are  allotted. 
Merely  acknowledging  that  the  user  should  be 
involved  does  not  guarantee  user  involvement. 
Higher  eschelon  management  must  be  made  aware  of 
such  requirements  early  on  so  that  adequate 
foundations  for  manpower,  budget,  and  support 
are  available  when  required.  Also  during  plan¬ 
ning  the  user  should  provide,  as  appropriate, 
inputs  on  the  problem;  on  similar  systems;  on 
the  system  being  replaced;  and  on  the  intended 
purpose,  environment,  and  personnel  for  the  sys¬ 
tem.  If  possible,  face-to-face  interface  should 
occur  during  the  planning  stage.  This  type  of 
interaction  will  provide  the  user  with  a  better 
understanding  of  the  limitations  and  constraints 
under  which  the  software  engineers  labor,  and 
vice  versa.  The  user  should  endeavor  to  become 
better  familiar  with  the  software  engineer's 
frame  of  reference  and  language.  A  person's 
frame  of  reference  is  made  up  of  those  events, 
experience,  and  knowledge  he/she  has  been  ex¬ 
posed  to  that  shape  his/her  perspective  on  real¬ 
ity  and  in  particular  on  the  task  to  be  accom¬ 
plished.  LanguT^e  in  this  context  refers  to  the 


communication  moans  and  in.uf.-s  ot  an  mdivi-.lii.il 
and  covers  verbal  and  nonverbal  i  <>mmun  i  c  at  .  .ui  a- 
We  1 1  as  sub  tie  tv  o 1  the  common  vernacular.  Ih. 
closer  one's  t  r  a me  of  reference  and  language  ar> 
to  another's  the  more  precisely  th.-y  can  cmiinir 
nicate. 

User  inputs  were  elicited  during  the  plan¬ 
ning  stage  from  the  S-3A  community.  I'n  fortu¬ 
nately,  the  user's  stated  requirements  exce.-d*d 
legal  boundaries  and  common  procurement  prac¬ 
tices  and  had  to  be  ignored.  This  apparent 
"snub"  led  to  difficulties  throughout  the  pro¬ 
gram.  User  inputs  have  been  elicited  during  the 
planning  stage  for  the  two  emerging  systems,  and 
management  has  been  in  support  ot  Fleet  Project 
Team  participation.  In  all  cases  the  user  has 
seemed  very  eager  to  provide  inputs  to  the  anal¬ 
ysis  of  the  problem  and  to  the  resolution  of  the 
problem.  The  user  has  been  in  direct  contact 
with  the  software  engineers,  and  a  give-and-take 
and  nonantagon is t ic  atmosphere  has  been  estab¬ 
lished.  Personality  differences  can  be  skill¬ 
fully  controlled,  but  not  necessarily  elimi¬ 
nated.  Success  in  establishing  and  maintaining 
a  relationship  that  generates  a  user-friendly 
system  seems  to  be  dependent  upon  the  presence 
of  a  free  and  open  environment  for  discussion 
with  a  single  moderating  body  in  attendance. 
Someone  with  authority  and  a  "big-picture"  per¬ 
spective  needs  to  be  involved  directly  to  keep 
discussions  from  getting  out  of  hand,  either  on 
a  personal  level  or  into  a  dream  world. 

User  inputs  during  the  analysis  stage  are 
probably  the  most  critical  of  all  inputs 
throughout  the  software-generation  process.  It 
is  during  this  stage  that  the  user  friendliness 
of  the  system  is  first  defined,  and  it  is  from 
the  end-product  of  analysis  that  deviations  are 
made  at  latter  stages  in  the  process.  The  user 
should  ensure  that  the  following  items,  synthe¬ 
sized  from  available  literature  (references  1  - 
4),  are  addressed  in  the  functional  description 
of  the  system  which  is  generated  during  the 
analysis  stage. 

o  User  language 

o  User  logic  (psychology  or  pattern  of 
thought ) 

o  Means  to  recover  from  user  error 
o  Help  available 

o  Level  of  effort  estimated  to  achieve 
tasks 

o  Amount  of  training  required 
o  Data  configuration 
o  Data  access  procedures 
o  Security  procedures 

o  Human  factors  related  to  the  man-machine 
interface 

o  Use  of  CGI  (graphics) /visuals. 

The  functional  description  of  the  system 
software  should  describe  the  language  the  system 
will  use  to  interface  with  the  user.  As  stated 
earlier,  unfamiliar  language  usage  leads  to  a 
burden  on  the  part  of  the  user  to  acquire  new 
terminology,  jargon,  and  subtleties  of  the  lan¬ 
guage.  A  model  of  the  user,  how  he/she  accom¬ 
plishes  a  job  using  the  system,  should  also  be 
contained  in  the  functional  description.  Flow 
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diagrams,  logic  trees,  and  other  pictorial  des¬ 
criptions  should  accompany  any  textual  documen¬ 
tation  concerning  the  user's  logic  in  problem 
solving  or  system  use. 

In  face-to-face  communication  it  is  possi¬ 
ble  to  get  lost  or  lose  a  train  of  thought;  the 
human-computer  interface  should  provide  obvious 
means  of  recovery  from  such  a  disconnect  eventu¬ 
ality.  Interruptions,  memory  lapses,  daydream¬ 
ing,  and  other  mental  and  physical  occurrences 
can  lead  to  communication  interruption.  The 
functional  description  should  provide  data  on 
how  the  system  will  indicate  status  to  the  user, 
how  the  user  will  be  able  to  recover  from  er¬ 
rors,  and  what  assistance  the  system  will  pro¬ 
vide  when  the  user  is  unsure  of  functions,  how 
to  proceed,  etc. 

The  functional  description  should  also  in¬ 
clude  an  indication  of  the  average  level  of  ef¬ 
fort,  the  number  of  actions,  the  total  amount  of 
time,  etc.,  estimated  to  achieve  tasks.  The 
level  of  effort  should  directly  relate  to  the 
difficulty  of  achieving  the  task  and  the  com¬ 
plexity  of  the  subtasks  that  make  up  the  task. 
The  user  should  make  sure  that  simple  tasks,  as 
defined  separately  from  the  computer,  such  as  a 
simple  multiplication  task,  require  a  simple- 
action  instruction  on  the  part  of  the  user. 

This  does  not  mean  that  complex  tasks  should 
require  complex  user  action  or  instruction; 
rather  the  system  should  simplify  for  the  user, 
whenever  possible,  the  procedural,  instruc¬ 
tional,  and  interpretat ional  requirements  of  the 
system.  If  a  task  can  be  automated,  and  the 
user  need  not  be  directly  involved,  then  the 
system  should  not  require  anything  from  the 


The  functional  description  should  contain 
an  estimate  of  the  amount  of  training  required 
for  the  user  of  the  system.  This  estimate 
should  cover  initial  training  and  follow-on 
training  requirements.  Software  trade-offs  are 
often  made  at  the  cost  of  additional  training. 
The  user  should  be  aware  of  the  impacts  of  such 
trade-offs,  and  the  software  engineer  should  be 
forced  to  define  up-front  the  basis  upon  which 
future  trade-offs  will  be  made.  Data  configura¬ 
tion,  data  access,  and  security  procedures 
should  be  delineated  in  the  functional  descrip¬ 
tion  to  ensure  that  all  will  be  properly  and 
adequately  addressed  in  the  design.  The  con¬ 
figuration  of  the  data  can  have  an  impact  on  how 
the  data  is  manipulated  and  formatted  for  ouput. 
Assurances  should  be  made  at  the  analysis  stage 
that  the  activities  of  the  user  can  be  accom¬ 
plished  given  the  data  configuration.  The  user 
should  probe  the  functional  description  with  the 
same  questions  and  activities  expected  of  the 
end-product  system  to  determine  the  limitations 
and/or  inadequacies  of  the  analysis.  In  this 
regard  the  user  should  ensure  his/her  involve¬ 
ment  in  testing  the  system  throughout  the 
software-generation  cycle.  The  user  should  en¬ 
sure  that  adequate  time  and  test  points  are 
identified  in  the  acceptance  plan.  If  possible, 
the  user  should  encourage  test  trials  of  part  or 
the  whole  of  the  system  software  interface  to 
coincide  with  software  engineering  and  testing 
activities. 


User  inputs  were  elicited  during  the  analy¬ 
sis  stage  trom  the  S-lA  community,  and  a  func¬ 
tional  description  was  produced  tor  the  system. 
However,  the  list  of  items  described  above  as 
areas  to  be  addressed  in  the  analysis  stage  was 
not  developed.  The  user  had  a  poor  conceptuali¬ 
zation  of  what  was  needed  and  what  the  system 
was  to  provide.  The  users'  review  comments  re¬ 
flected  a  lack  of  understanding  in  that  their 
major  concern  was  where  the  system  would  be 
sited  rather  than  how  it  would  operate.  The  V7 X 
user-community  has  been  intimately  involved  in 
the  analysis  stage  of  software  generation  t>> 
support  the  simulators,  the  TIS,  and  the  academ¬ 
ics  subsystem.  Specifications  have  been  written 
to  functionally  describe  these  three  subsystems. 
Again,  the  list  of  items  to  be  addressed  in  the 
analysis  stage  was  not  developed  prior  to  elic¬ 
iting  user  inputs.  Nevertheless,  the  users  and 
the  software  engineers  have  had  several  face-to- 
face  formal  sessions  to  interact  and  to  discuss 
how  the  software  can  best  support  the  needs  of 
the  users.  The  E-6A  user-community  is  in  the 
process  of  meeting  with  the  software  engineers 
to  discuss  the  software  analyses  to  support  E-6A 
requirements.  The  E-6A  Fleet  Project  Team  will 
use  the  list  of  items  to  be  addressed  in  the 
analysis  stage  during  their  evaluation  of  the 
flight  simulator  functional  specification. 

The  design  stage  is  an  extension  of  the 
analysis  effort.  During  design  the  user  should 
strive  to  ensure  consistent  application  of  the 
analysis  stage  outputs  to  the  design  of  the 
software.  The  user  should  revisit  the  analysis 
data  to  determine  whether  all  requirements  in 
fact  were  addressed.  Modification  to  the  basic 
analysis  data  is  most  easily  accomplished  prior 
to  entering  the  production  and  test  stage.  If 
possible,  the  user  should  evaluate  software  pro¬ 
cedures  and  system  displays  and  cues  on  mock-up 
or  paper  product  versions  of  the  intended  end- 
product  system.  Flipping  through  sample  menus 
as  they  would  appear  during  software  interface 
can  provide  a  general  level  of  appreciation  for 
what  the  end-product  will  look  like.  At  this 
stage  in  the  process  trade-offs  will  begin  to 
arise.  Software  trade-offs  are  the  result  of 
hardware  constraints,  operating  software  con¬ 
straints,  lack  of  engineering  creativity,  and 
the  cost  of  generation.  It  is  often  during  de¬ 
sign  that  a  distinction  is  made  between  "need  to 
have"  and  "nice  to  have"  or  "whistles  and  bells" 
requirements.  All  trade-offs,  whether  they  fit 
"need"  or  "want"  criteria  or  they  are  due  to 
system*  or  fiscal  constraints,  should  be  docu¬ 
mented  and  justified.  This  information  provides 
support  data  for  future  funding  requests  and 
provides  the  basis  for  future  system  enhance¬ 
ments. 

The  S-3A  user-community  was  provided  with 
an  opportunity  to  review  the  design  of  the  data 
base  system  on  a  paper  product  set  of  example 
menus.  These  sample  menus  took  the  reviewer 
through  all  modes  of  operation  and  demonstrated 
step-by-step  the  procedures  the  user  would  go 
through  to  accomplish  activities.  Since  the 
user  was  not  really  cognizant  of  the  purpose  of 
the  analysis  and  how  it  fit  with  the  design,  no 
consistency  evaluation  was  made  by  the  user. 

The  result  was  that  the  concept  changed  as  the 
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system  evolved  without  any  audit  trail  back  to 
the  original  analysis.  Trade-offs  were  made  and 
were  not  well  documented,  mainly  because  at  the 
time  no  requirement  was  levied  on  the  software 
engineers  to  provide  such  documentation.  The 
VTX  and  the  E-6A  programs  have  not  fully  evolved 
to  the  design  stage  of  the  software-generation 
process.  However,  it  is  anticipated  that  during 
design  reviews  the  user-community  representa¬ 
tives  will  evaluate  the  design  for  consistency 
and  will  request  documentation  of  all  deviations 
from  the  original  analysis. 

The  production  and  test  stage  of  the  pro¬ 
cess  involves  software  coding  activities  that 
result  in  actual,  visual  products  that  the  user 
can  interface  with.  The  user  should  push  and 
probe  the  software  to  its  limits.  A  user  un¬ 
familiar  with  the  system  can  provide  better  in¬ 
sight  to  interface  problems  and  can  directly 
assist  in  the  debugging  effort.  This  increased 
faculty  is  a  result  of  user-naivete  with  regard 
to  how  the  system  was  evolved  from  the  design. 
The  errors  and  bugs  discovered  during  production 
and  test  are  those  most  likely  to  be  repeated  in 
the  final  product  if  the  user  is  not  involved  in 
the  interim  eesting.  The  user  can  also  assist 
in  identifying  design  inadequacies  or  design- 
production  inconsistencies  with  respect  to  the 
human-software  interface. 

Constraints  in  the  S-3A  program  limited 
production  and  testing  to  non-users  and  contrac¬ 
tor  personnel.  The  program  ran  into  hardware 
and  software  operating  system  constraints  that 
affected  schedules  and  resources  to  complete  the 
program.  Testing  by  operators  was  not  conducted 
in  a  systematic  manner  until  the  integration 
stage  was  complete.  The  VTX  and  E-6A  programs 
have  programmed  time  into  their  schedules  for 
user-community  representatives  to  be  directly 
involved  in  quality  assurance  during  software 
production  and  unit  testing.  It  is  anticipated 
that  full-time  personnel,  exclusively  assigned 
to  support  the  E-6A  program  development,  will  be 
available  to  provide  user  inputs  during  produc¬ 
tion  and  testing. 

Typically,  the  user  is  not  involved  with 
system  testing  during  the  integration  stage.  If 
provided  with  the  opportunity,  however,  the  user 
should  test  the  entire  system  as  an  integrated 
whole  during  integration  and  during  acceptance. 
The  difference  between  tests  conducted  during 
integration  and  during  acceptance  is  a  matter  of 
the  timing  and  the  expected  level  of  quality 
control.  The  testing  conducted  during  integra¬ 
tion  should  elicit  more  programming  errors  yet 
to  be  debugged  than  the  testing  conducted  during 
acceptance.  The  system  should  be  installed  on¬ 
site  or  should  be  ready  for  packing  and  shipping 
at  the  completion  of  acceptance  testing.  Inte¬ 
gration  testing,  on  the  other  hand,  can  be  ac¬ 
complished  in  the  lab.  The  user  should  validate 
the  procedures  and  other  information  defined  in 
the  operations  and  maintenance  manuals,  user 
manuals,  and  training  materials  to  verify  that 
the  support  documentation  supports  the  system 
beyond  acceptance  and  implementation.  During 
acceptance  the  user  also  has  a  responsibility  to 
review  the  specification  requirements  and  all 
trade-offs  made  during  the  software-generation 


process.  The  user  should  ensure  that  all  devia¬ 
tions  from  the  original  requirements  and  all 
trade-offs  are  adequately  documented  with  justi¬ 
fication  for  each. 

The  S-3A  user-community  was  not  involved  in 
integration  testing  or  acceptance  of  the  train¬ 
ing-related  data  base  system.  This  lack  of  in¬ 
volvement  has  led  to  a  lack  of  interest  in 
using,  and  possibly  maintaining,  the  data  base 
system.  Integration  testing  and  system  accep¬ 
tance  was  conducted  by  Navy  personnel  familiar 
with  the  program  and  the  system  design.  The  VTX 
and  E-6A  programs  will  have  user-community  rep¬ 
resentatives  directly  involved  with  acceptance 
testing.  As  in  the  case  of  the  production  and 
testing  stage,  full-time  personnel  will  be 
available  to  support  E-6A  quality  assurance 
testing  throughout  the  integration  stage. 

The  final  stage  in  the  software  generation 
process  has  an  ongoing,  everpresent  requirement 
for  the  user  to  actively  participate  in  the 
maintenance  and  improvement  of  the  system  soft¬ 
ware.  The  user  should  document  system  errors  or 
bugs,  identify  any  inadequacies  of  the  system, 
and  provide  constructive  inputs  to  enhance  the 
system.  Constructive  feedback  to  software  engi¬ 
neers,  programmers,  and  management  provides  im¬ 
portant  information  for  further  system  develop¬ 
ment  and  development  of  similar  systems.  The 
user  should  also  assist  in  the  development  of  a 
software  configuration  managment  instruction 
(CMI)  that:  1)  governs  the  establishment  and 
provides  a  charter  for  a  Software  Configuration 
Change  Board  (SCCB)  and  2)  identifies  the  means 
to  ensure  reliable  and  valid  software  at  all 
times. 

A  CMI  was  written  to  support  the  S-3A 
training-related  data  base  system.  However, 
funding  constraints  and  apparent  lack  of  inter¬ 
est  on  the  part  of  the  users  have  led  to  almost 
complete  neglect  of  the  system.  Other  naval 
communities  and  industry  have  expressed  interest 
in  the  underlying  concept  of  the  system.  The 
S-3A  user-community,  having  never  taken  owner¬ 
ship  for  the  system,  may  never  realize  the  full 
benefit  of  the  system.  A  significant  lesson 
learned  from  the  S-3A  program  is  that  the  user’s 
inputs  cannot  be  sacrificed  for  expediency.  The 
system  eventually  must  pay  for  its  lack  of  at¬ 
tention  to  user  friendliness.  The  VTX  and  E-6A 
programs  require  configuration  management  plan¬ 
ning  as  contract  requirements.  Hopefully,  user 
involvement  in  these  programs  will  continue  to 
be  supported  throughout  the  system  generation 
process  and  on  into  the  out  years  of  the  system 
life  cycle.  With  the  VTX  and  the  E-6A  programs 
the  U.S.  Navy  has  an  opportunity  to  demonstrate 
that  user  involvement  contributes  to  a  more 
user-friendly  system  and  thereby  to  demonstrate 
that  user  friendliness  contributes  to  efficient 
and  effective  training. 

SUMMARY 

User-friendly  computer  software  is  software 
that  adapts  to  the  user's  perspective  and  allows 
communication  to  occur  between  the  computer  and 
the  user.  User-friendly  software  speaks  the 
same  language  as  the  user  regardless  of  the  type 
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or  level  of  user.  The  only  way  Co  ensure  user- 
friendly  software  in  the  end-product  is  to  en¬ 
sure  direct  user  involvement  at  the  initial  step 
of  the  software-generation  cycle  and  continued 
interaction  throughout  the  subsequent  steps  of 
the  process.  This  interaction  does  not  occur 
spontaneously.  Adequate  funding  and  authoriza¬ 
tion  from  procuring  agencies  and  high  eschelon 
management  must  be  secured.  Extensive  travel  is 
typically  a  requirement  of  user  support  to  the 
software  generation  process.  Additionally, 
front-end  money  to  develop  adequate  functional 
descriptions  and  to  perform  the  necessary  analy¬ 
ses  is  required.  Moreover,  time  must  be  made 
available  for  dedicated-users  to  support  review 
activities.  These  requirements  can  appear  to  be 
costly;  however,  the  benefit  gained  through  more 
efficient,  effective  use  of  the  system  resulting 
from  user  acceptance  and  a  feeling  of  mutual 
understanding  of  the  user  with  the  computer  sys¬ 
tem  far  outweighs  the  initial  investment  to  en¬ 
sure  a  high  degree  of  user  friendliness. 
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ABSTRACT 

The  problem  of  developing  and  sustaining  armor  crew  gunnery  proficiency  has  become  increasingly  challenging 
in  recent  years  due  to  operational  and  training  costs  and  limited  range  availability  for  realistic  gunnery  training 
The  Unit-Conduct  of  Fire  Trainer  (U-COFT)  was  thus  developed  to  provide  armor  for^,u  commanders  the  capability 
for  improving  and  sustaining  crew  gunnery  combat  readiness  between  range  firing  periods  A  total  training 
system  consisting  of  crew  station,  visual,  and  instructional  subsystems,  the  U-COFT  is  housed  in  three  en 
vironmentally  controlled  shelters  that  afford  limited  mobility  and  self  contained  operation  II  will  be  deployed 
with  armor  and  infantry  battalions  in  44  locations  throughout  the  free  world  The  U  COFT  instructional  system 
features  an  extensive  library  of  exercises  which  train  all  the  gunnery  tasks  required  ot  a  crew  in  combat  plus 
an  adaptive  training  management  function  that  permits  each  crew  to  improve  its  proficiency  at  a  rate  common 
surate  with  its  ability.  This  paper  briefly  describes  the  unique  instructional  features  incorporated  in  the  U  COFT 
training  systerr^ 


INTRODUCTION 

With  the  largest  training  device  contract  ever  awarded,  the  U  S 
Army  is  sponsoring  the  manufacture  and  fielding  of  nearly  300 
Unit-Conduct  of  Fire  Trainer  (U-COFT)  systems  configured  for  the 
Ml  Abrams  and  M60A3  tanks,  and  M2/M3  Bradley  fighting 
vehicles.  Employing  computer  image  generation,  digital  control 
systems,  and  computer  aided  instruction  techniques,  the  U-COFT 
is  designed  to  train  armored  vehicle  commanders  and  gunners 
in  basic,  intermediate,  and  advanced  gunnery  skills.  Providing 
crew  compartments  that  closely  replicate  actual  turret  interiors, 
generating  high  resolution  full-color  imagery  viewed  through 
sights  and  periscopes,  and  accurately  simulating  the  sight, 
sound,  and  "feel"  of  fire  control  system  and  weapon  operation, 
the  U-COFT  demonstrated  training  effectiveness  during  opera¬ 
tional  testing  by  the  U.S.  Army.  A  key  factor  in  its  capability  as 
a  training  device  is  the  instructional  subsystem  used  to  direct, 
evaluate,  and  monitor  the  training  process  Highlights  of  the  U- 
COFT  development  and  operational  testing,  system 
characteristics,  and  instructional  subsystem  features  are 
provided  in  subsequent  paragraphs. 


PROTOTYPE  DEVELOPMENT  AND  VALIDATION 

In  September  1979  the  U.S.  Army  awarded  contracts  to  two  con 
tractors  for  accelerated  development,  over  a  21 -month  period, 
of  prototype  versions  of  an  Ml  configured  U-COFT  on  a  com 
petitive  "best-effort"  basis.  That  is.  both  contractors  were 
allowed  maximum  latitude  in  design  of  the  trainers,  so  long  as 
certain  minimum  performance  requirements  were  met  Govern 
ment  evaluation  and  selection  of  the  production  contractor  was 
to  be  based  heavily  on  the  training  effectiveness  demonstrated 
during  field  testing.  At  the  end  ot  the  contractually  fixed 
development  period,  only  one  contractor  successfully  fielded 
an  operational  system  Development  of  M2  and  M60  versions 
was  continued  with  the  winning  contractor.  General  Electric  A 
production  award  followed  in  September  1982 

Assessment  of  the  training  capability  of  the  General  Electric,  U 
COFT  occurred  during  a  full-scale  operational  test  at  Fort  Hood 
Texas,  involving  a  battalion  of  Ml  crewmen  and  vehicles 


The  test  was  designed  to  measure  thr,-  capability  of.  and  dif¬ 
ferences  between,  two  training  programs  developed  to  train  crew 
gunnery.  Training  eltectiveness  was  measured  within  each  pro 
gram,  in  terms  of  skills  developed  and  increased  proficiency 
Transfer  effectiveness  was  measured  in  terms  ot  crew  proficiency 
—  either  sustained  or  increased  —  resulting  from  the  train  ng 
programs  as  demonstrated  on  the  actual  Ml  tank 

In  the  test  plan  devised,  one  armor  company  was  to  tram  usmq 
the  actual  Ml  tank  together  with  other  conventional  training  aids, 
two  other  companies  were  to  receive  gunnery  tramma  exclusively 
on  the  U-COFT  yet  perform  all  other  normal  crew  tasks  during 
the  three  month  iraining/evaluation  period  Prior  to  start  of  Ihe 
training  period  all  three  companies  participated  in  a  range  firing 
test  to  assess  basrc  crew  proficiency  levels  At  the  conclusion 
of  training  a  second  range  firing  exercise  was  conducted  and 
graded,  and  the  results  compared  to  the  pretraining  scores 

Final  test  results  concluded  that  both  training  programs  sus 
tained  proficiency:  each  provided  a  satisfactory  level  of  transfer 
effectiveness.  Additionally,  the  U-COFT  was  found  to  be  tram 
ing  effective  in  that  as  a  training  medium  it  sustained  and  in  some 
cases  improved  gunner  and  tank  commander  skills  m  all  areas 
measured.  Moreover,  a  supplementary  test  designed  to  assess 
the  ability  of  both  tank  and  COFT  trained  crews  to  operate  with 
malfunctioning  fire  control  equipment  indicated  that  crews 
trained  on  the  COFT  were,  in  fact,  clearly  superior  This  was  not 
unexpected  since  crews  training  on  the  U-COFT  experience  pro 
grammed  malfunctions  as  part  of  the  exercise  matrix  and  hence 
become  more  familiar  with  procedures  to  follow  when  confronted 
with  failed  or  degraded  weapon  system  components  A  fourth 
Ml  tank  company  newly  formed  immediately  prior  to  the  start 
ot  Ihe  test,  and  which  could  not  be  officially  "  included,  was  also 
involved  This  company  was  largely  but  not  entirely  composed 
ot  personnel  untrained  on  the  Ml.  and  due  to  Ihe  non 
homogeneous  mix  did  not  represent  a  true  transition  qroup  This 
company  was.  however  trained  solely  on  the  COFT  with  a  course 
of  instruction  designed  tor  transition  training,  the  length  of  which 
was  approximately  three  tirrms  that  of  the  sustainment  com 
pamos  Approximately  two  thirds  of  the  way  through  this  tram 
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ing  the  skill  levels  demonstrated  on  the  COFT  were  beginning 
to  match  those  achieved  by  the  sustainment  crews;  at  the  com¬ 
pletion  of  the  test,  the  skill  levels  of  the  transition  company, 
demonstrated  on  the  COFT.  equalled  or  bettered  those  of  the  sus¬ 
tainment  companies.  These  findings  are  expected  to  be  verified 
by  planned  testing  when  the  U-COFT  reaches  field  units. 

PRODUCTION  SYSTEM  DESCRIPTION 

As  illustrated  in  Figure  1.  the  U-COFT  is  composed  of  the 
following  hardware  elements: 

•  A  crew  station  in  which  the  appearance  and  functions  of 
training-critical  vehicle  operating  controls,  indicators,  and 
weapon  sights  are  replicated. 

•  A  computer  image  generation  (CIG)  visual  system  that  pro¬ 
duces  realistic,  full-color  action  scenes  allowing  crew 
members  to  view  and  interact  with  a  broad  range  of  target 
situations. 

•  An  instructor-operator  station  (IOS)  through  which  the  in¬ 
structor  (a  master  gunner  or  platoon  sergeant)  initiates  the 
computer-selected  exercises  and  monitors  crew  perfor¬ 
mance  He  can  freeze  action,  replay  all  or  part  of  a  par¬ 
ticular  exercise,  select  remedial  exercises  to  suit  specific 
crew  needs,  or  obtain  soft  or  hard  copies  of  crew  perfor¬ 
mance  Color  displays  included  in  the  station  let  him  view 
all  visual  scenes  as  presented  to  the  trainees 

•  A  general-purpose  computer  which  provides  the  control  in¬ 
terface  between  system  elements,  as  well  as  manages  the 
total  U-COFT  training,  scheduling,  and  performance/ 
proficiency  evaluation 

•  A  shelter  subsystem  composed  of  three  air-transportab!e 
MIL/ISO  standard  containers,  with  two  of  these  housing 
the  trainer  equipment  and  the  third  providing  space  for 
crew  briefing/debriefing  and  maintenance.  Environmental 
conditioning,  power  distribution,  and  fire  protection  is  self- 
contained 


The  special  purpose  computer  image  generator  provides  three 
dimensional  color  daylight,  reduced  visibility  and  mqht  scenes 
with  various  terrain  and  topographical  backgrounds  manmade 
structures,  moving  targets,  proiectile  tracers,  and  special  effects 
(round  impact,  missile  signature,  artillery  fire  —  both  friendly  and 
enemy,  smoke  grenade  explosion,  etc  )  that  allow  tank  crews  to 
develop  gunnery  proficiency  in  a  variety  of  simulated  battle  con 
ditions.  Correct  visual  perspective  is  instantaneously  computed 
and  maintained  for  all  orientations  of  the  simulated  vehicle 
targets  and  overall  data  base.  The  lOkm-by  7km  data  base  around 
which  the  training  exercises  are  developed  is  composed  of  eight 
separate  data  blocks:  six  ot  these  can  be  moved  or  interchanged 
to  provide  scene  flexibility  Ownvehicle  can  be  programmed  for 
movement  through  seven  of  the  eight  blocks:  targets  can  be 
placed  anywhere  in  the  data  base.  Weapons  simulated  include 
the  105  mm  mam  gun.  7.62  mm  coaxial  machine  gun.  50  caliber 
machine  gun.  and  smoke  grenades  used  on  the  Ml  and  M60 
tanks,  and  the  25  mm  automatic  weapon.  7.62  mm  machine  gun 
and  TOW  missile  system  used  on  the  M2/M3  fighting  vehicles 
Data  bases  are  available  for  both  visible  and  thermal  engagement 
exercises;  in  the  latter,  thermal  signatures  of  scene  objects  and 
targets  are  taken  into  account  to  assure  realism. 


Over  500  tactical  exercises,  each  approximately  10  minutes  long, 
are  available  for  the  Ml  U-COFT.  The  M60  version  will  be  equipped 
with  a  comparable  number,  and  the  M2/M3  will  have  more  than 
350.  These  exercises  range  from  a  three-hour  introductory  ses¬ 
sion  for  trainee  familiarization  with  the  U-COFT  and  orientation 
in  basic  elements  of  tank  gunnery,  to  complex  multiple-target 
air/ground  exercises  which  test  the  mettle  of  even  the  finest  tank 
crews.  Ranking  of  the  exercises  is  in  order  of  increasing  diffi 
cutty  in  each  of  three  skill  areas:  target  acquisition,  reticle  aim 
ing.  and  systems  management.  By  a  systematic  method  of  but¬ 
ting  and  stacking,  these  exercises  form  a  three-dimensional 
matrix  through  which  a  student  advances—  on  an  exercise-by- 
exercise  basis— toward  certification  levels  established  for  basic. 


cross,  transition,  ant)  sustainment  courses  of  instruction  Rank 
mg  the  exercises  according  to  difficulty  makes  controlled  adap 
five  learning"  possible,  in  that  the  student  progresses  to  the  next 
successive  exercise  (or  level  of  difficulty)  only  if  his  current  and/or 
previous  performance  justifies  if  He  either  advances,  regresses, 
or  remains  at  the  same  level  in  accordance  with  pre-established 
matrix  movement  rules  and  conditions  that  will  be  discussed 
later  For  each  exercise  in  the  commander/gunner  and  com¬ 
mander  matrices,  there  are  either  two  or  four  repetitions  of  that 
exercise  available.  In  the  case  of  stationary  ownvehicle  exercises, 
each  exercise  has  four  repetitions  in  which  the  situation  condi¬ 
tions  are  the  same  but  the  order  of  appearance  of  the  targets 
is  changed  For  moving  ownvehicle  exercises,  there  are  two 
repetitions,  each  of  these  being  a  unique  exercise  since  in  a  mov¬ 
ing  exercise  merely  changing  the  order  of  appearance  could 
mean  that  the  target  would  not  be  visible  due  to  ownvehicle  posi¬ 
tion  at  that  time.  The  repetitions  are  utilized  when  the  computer 
recommends  "no  advancement"  and  the  crew  is  required  to 
retrain  at  that  same  difficulty  level.  The  repetition  capability  also 
serves  to  deter  crew  memorization  of  exercise  content  and  target 
appearance. 


As  students  progress  through  the  matrix,  they  move  from 
simple  stationary  owntank-stationary  target  engagements  to 
increasingly  difficult  conditions  involving  various  combinations 
of  moving  ownvehicle.  moving  targets,  multiple  stationary  and 
moving  targets,  reduced  visibility,  malfunctioning  fire  control 
components,  and  incoming  enemy  fire.  Overall,  an  extremely 
realistic,  effective,  and  stringently  controlled  training  environ¬ 
ment  results. 


INSTRUCTIONAL  SUBSYSTEM 

The  instructional  approach  employed  in  the  U  COFT  has  evolved 
as  the  result  of  inputs  from  tank  crewmen,  engineers  educators 
training  psychologists,  training  managers,  project  managers,  and 
other  sources,  and  has  proved  to  be  extremely  effective  to  date 
in  achieving  the  Army's  goals  for  this  trainer.  The  U  COFT  instruct 
tional  subsystem  consists  of  a  library  of  preprogrammed  exer 
cises  for  teaching  gunnery  skills,  an  adaptive  evaluation  system 
for  evaluating  crew  progress,  a  training  management  system  to 
process  student  records  and  assist  in  scheduling,  and  an  Instruc 
tor  Operator  Station  (IOS)  to  provide  the  instructor  with  real-time 
instructional  feedback  and  control  features  (o  aid  in  monitoring 
and  critiquing  student  actions 


Training  Matrix 

As  discussed  earlier,  the  framing  exercises  form  a  matrix,  as 
illustrated  in  Figure  2.  that  is  organized  according  to  target  ac¬ 
quisition.  retical  aiming,  and  systems  management  levels  of  dif¬ 
ficulty.  Ranking  exercises  in  this  manner  makes  possible  an 
adaptive  learning  process  that  is  controlled  by  selection  of  ex¬ 
ercises  of  known  change  in  difficulty  based  on  trainee  perfor¬ 
mance  on  previous  exercises  Target  acquisition  levels  of  diffi¬ 
culty  cover  a  range  of  targef  exposure,  visibility,  lighting,  friendly 
and  enemy  fire,  and  various  distracting  conditions  such  as  (her 
mal  clutter,  friendly  and  enemy  fire,  and  friendly  vehicles  in  the 
target  areas.  The  reticle  aim  levels  are  ranked  by  difficulty  by  fore- 
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mg  the  use  of  primary  and  auxiliary  gunsights  either  with  or 
without  fire  control  system  malfunctions  present  and  required 
use  of  NBC  (Nuclear.  Biological.  Chemical)  equipment  by  the 
crew.  And  finally,  systems  management  levels  are  layered  accord 
ing  to  whether  single  or  multiple  targets  are  present,  and  to 
respective  target  range.  There  is  a  similar  but  smaller  matrix 
which  consists  of  exercises  designed  specifically  tor  the  train 
mg  of  the  tank  commander  (TC).  and  the  firing  of  the  various 
weapons  from  the  TC  position 


The  exercises  comprising  the  commander, 'gunner  and 
commander-only  matrices  are  organized  into  groups,  with  each 
group  addressing  a  specific  type  of  ownvehicle  motion  and  target 
mix.  Each  exercise  in  the  group  consists  of  from  four  to  ten  in¬ 
dependently  scored  situations  with  similar  tactical  and  en¬ 
vironmental  conditions.  Each  grouo  contains  a  mixture  of  target 
types,  both  friendly  and  enemy,  including  tanks,  armored  person¬ 
nel  carriers,  trucks,  helicopters,  and  area  (troop  fire)  targets,  and 
is  structured  according  to  the  target  acquisition  and  reticle  aim 
levels  of  difficulty.  In  each  of  the  first  five  groups  or  blocks  of 
exercises  shown  in  Figure  2.  each  group  provides  seven  types 
of  reticle  aim  problems,  with  three  degrees  of  difficulty  in  target 
acquisition,  and  two  or  four  levels  of  difficulty  in  systems 
management.  As  the  crew  progresses  from  Group  1  through 
Group  6.  the  conditions  become  more  difficult  as  the  owntank 
targets  proceed  from  stationary  to  moving,  and  from  single  to 
multiple. 


Following  an  orientation,  trainees  enrolled  in  the  basic  course 
of  instruction  enter  the  matrix  at  the  beginning  position  shown 
in  Figure  2.  After  completing  an  expected  number  of  exercises, 
progressing  along  a  nominally  diagonal  movement  through  the 
layered  groups  of  exercises,  the  trainees  exit  the  matrix  at  the 
point  where  certification  for  the  basic  course  is  achieved.  That 
is,  at  that  point  exercises  are  provided  which  test  the  capability 
of  the  crew  to  proceed  to  the  more  difficult  sustainment  blocks 
of  exercises. 


Trainees  in  the  cross  training  program  category  enter  the  matrix 
at  a  more  advanced  level  than  that  specified  for  basic,  but  then 
move  toward  certification  in  similar  fashion  as  those  students 
in  the  basic  course.  Transition  and  sustainment  trainees  enter 
the  matrix  at  yet  higher  levels  and  after  completing  their  respec¬ 
tive  expected  number  of  exercises  achieve  certification  at  the 
uppermost  point  of  the  matrix. 


The  training  exercises  provide  for  moving  or  stationary  firing, 
ownvehicle  in  combination  with  moving  or  stationary  targets 
Target  and  ownvehicle  motion  is  preprogrammed  to  assure  that 
all  trainees  at  all  unit  locations  are  measured  in  the  same  way. 
allowing  random  "wandering''  may  involve  heavy  reliance  on  in¬ 
structor  judgement  and  result  in  inconsistencies  in  scoring  For 
stationary  engagement  exercises,  motion  paths  such  as  those 
representing  movement  from  and  to  defilade  positions  connect 
stationary  firing  positions,  for  stationary  target  exercises,  the 
paths  cause  the  targets  to  move  into  view  and  then  remain  sta 
tionary  until  the  exposure  time  limit  is  reached.  In  all  cases,  the 
targets  withdraw  from  the  scene  it  not  hit.  In  no  cases  do  targets 
to  be  engaged  appear  or  disappear  suddenly  from  the  scene 
Ownvehicle  speed  is  specified  for  each  exercise  requiring 
ownvehicle  motion,  with  both  constant  and  variable  speed  and 
direction  paths  chosen  as  appropriate  for  the  obiectives  of  each 
exercise.  Exercises  provide  varied  terrain  roughness,  with 
ownvehicle  opera. ion  in  stabilized  and  nonstabilized  conditions. 


Targets  in  an  exercise  are  spaced  in  range  and  azimuth  to  pro¬ 
vide  training  in  target  search  and  acquisition.  Targets  become 
visible  within  two  or  three  seconds  after  the  start  of  each  situa¬ 
tion;  and  since  each  has  a  preprogrammed  exposure  time,  it 
withdraws  from  the  training  field  of  view  if  not  hit  within  the  time 
allowed  Vehicle  and  area  targets  appear  at  any  aspect  angle  with 
respect  to  the  viewing  ownvehicle.  from  full  front  to  full  rear  and 
including  all  angles  in  between  All  targets  may  be  programmed 
for  movement  throughout  the  data  base  gaming  area,  the  only 
restraint  beinq  the  existence  and  location  of  other  obiects  in  the 
data  base 


Turqoi  classification  levels  range  fn.ni  mi,-.t  iii.g.  i,  ,  i- 
friendly  with  each  target  in  a  silnati'.n  t ,»  .nt;  r  irn-i  w an 
respect  to  the  other  targets  in  the  •, qu.it. '.rs  Class. n  at-.  ■-  ■ 
based  c<n  the  follow  mg  variables  target  t  tig-  t  '  in-'-- 

target  orientation  (including  turret  (mentation  >n  the  a  •  -  ' 
tank  targets!  and  other  taigels  visible  Friendly  targets  .liw.i,- 
receive  the  lowest  classification  value,  and  the  levels  t  targi  !■ 
withm  the  same  lethality  grout,  are  equal  Engagement  m  ntd<  - 
of  lethality  is  one  of  the  criteria  considered  in  the  grading  o' 
crew  performance 


Training  the  commander  to  hie  the  mam  gun  and  tus  own  weapi  -n 
involves  use  of  the  commander's  exercise  matrix  which  is  similar 
to  the  commanderrgunnei  matrix  (Figure  2c  but  has  only  iv.u 
systems  management  levels  The  exorcises  m  this  matrix  ((re¬ 
organized  around  specific  types  ot  ownvehicle  motion  and  target 
mix.  and  each  exercise  includes  independently  scored  situations 
with  similar  tactical  and  environmental  conditions  Commander 
training  occurs  concurrently  with  crew  training  m  that  as  the  crew 
progresses  through  the  basic,  cross,  transition,  or  sustainment 
programs  the  computer  periodically  recommends  a  commander 
exercise.  Access  to  the  commander's  matrix  is  automatic  and 
progress  is  based  on  the  commander  s  learning  progtess  The 
first  commander's  exercise  is  automatically  selected  after  the 
third  computer-recommended  crew  exercise  but  thereafter  com 
mander  exercises  are  recommended  based  on  the  commander  s 
lag".  This  is  defined  as  the  difference  between  his  position  in 
the  commander's  matrix  versus  the  position  of  the  crew  in  its 
matrix,  and  can  be  positive  or  negative.  The  frequency  of  com¬ 
mander  exercises  can  vary  from  one  exercise  for  each  five  crew 
exercises  to  one  for  every  crew  exercise 


As  noted  previously  the  library  also  includes  special-purpose 
exercises  that  are  used  for  U-COFT  introduction.orientation. 
calibrafion  and  zeroing,  preparation  for  operation,  acquisition 
and  manipulation,  and  evaluation. 


Scoring  Criteria 

Each  U-COFT  framing  exercise  contains  a  minimum  of  four  to  a 
maximum  of  ten  independently  scored  situations  involving 
similar  tactical  and  environmental  conditions  A  situation  may 
involve  one.  two.  or  three  targets  which  may  be  stationary  or 
moving.  The  composite  of  situation  scores  for  a  given  exercise 
is  used  to  form  a  computer  recommendation  as  to  student 
movement  in  the  matrix 

Each  situation  is  scored,  on  the  basis  of  predetermined  criteria, 
for  performance  by  the  trainees  in  the  requisite  skill  dimensions 
of  target  acquisition,  reticle  aiming,  and  systems  management 
The  measured  state  for  each  dimension  is  determined  on  the 
basis  of  Ihe  criteria  listed  in  Table  1 


Skill 

Dimension 

State  Measurement  Criteria 

Target 

Acquisition 

•  Time  to  acquire  target 

•  Number  of  identification'classification 

errors 

Reticle 

Aiming 

•  Time  to  first  round  burst 

•  Time  to  hit 

•  Magnitude  of  aiming  error 

Systems 

Management 

•  Number  of  switch  setting  errors  prior 
to  firing 

•  Number  of  switch  setting  errors  at 
time  of  firing 

Table  1  Situation  Scoring  iMoasurod  Slatel  Criteria 
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To  illustrate  how  scoring  occurs  within  each  skill  dimension 
the  measurement  of  reticle  aiming  error  is  used  as  an  example 
This  error,  which  is  evaluated  for  mam  gun  rounds  only  is 
defined  as  the  total  distance  that  the  reticle  is  displaced  (tom 
the  centroid  of  fhe  target  or  from  the  correct  aiming  point  tor 
situations  requiring  manual  lead.  wind,  or  cant  aim  off  The  cor 
rect  target  aim  for  all  point  targets  is  within  a  0  67  mil  circle  of 
the  target  centroid  A  target  hit  plate  is  designed  tor  each  target 
type  such  that  the  portion  of  the  target  outside  the  0  67  mil  cir 
cle  but  within  the  target  silhouette  is  designated  as  sensitive  to 
hit  damage.  The  reticle  aim  error  evaluation  is  based  on  the 
criteria  indicated  in  Table  2 


Following  measurement  of  student  performance  in  each  skill 
area  the  evaluation  function  of  the  instructional  subsystem  ter 
mulates  recommendations  for  action  by  the  instructor  These 
are  displayed  on  the  IOS  terminal  CRT  at  the  conclusion  of  each 
exercise.  At  the  same  time,  a  disk  file  of  crew  performance  is 
automatically  updated:  this  file  is  catalogued  by  crew  member 
student  name,  and  training  program  type  (i  e  .  basic,  transition 
sustainment,  cross!  Access  to  student  records  is  under  strict 
password  control. 


Progression  through  the  commander/gunner  and  commander 
exercise  matrices  is  guided  by  matrix  movement  rules  desioned 
to  prevent  critical  levels  of  training  from  being  passed  over,  and 
to  present  exercises  of  remedial  content  to  students  for  whom 
reduction  in  standing  is  recommended  by  the  computer  The 
rules  also  assure  that  key  exercises  which  train  the  critical 
tasks  associated  with  a  reticle  aim  group  are  not  passed  over  as 
a  result  of  a  "rapid  advancement"  computer  recommendation 
After  an  exercise  is  completed  and  the  scores  for  each  of  the 
three  skill  dimensions  have  been  calculated,  the  system  checks 
the  movement  rules  against  the  computer  recommendation 
criteria  before  recommending  the  next  exercise.  The  matrix 
movement  rules  are  shown  in  Table  3. 


Round 

R‘-tn. 

n 

No 

f 

El  v  --iUj.it  it  >n 

(jr.l.l-- 

1 

i  Target  hit  and  ,em 

4 

A 

error  less  than  i  if 

equal  to  0  67  mil 

b  Target  hit  and  atm 

3 

B 

error  greater  than 

0  67  mil  but  wM thin  i 

the  hit  plate  area 

r  Target  missed  ,ind 

r 

F 

no  ser. on*  1  round 

fired 

rh 

C 

a  Target  hit  and  aim 

B 

error  less  than  <>t 

equal  to  0  67  mil 

b  Target  hit  and  a«m 

C 

error  greater  than 

0  67  mil  but  w i thin  fid  1 

plate  area 

c  Tdtqc-t  missed 

1 

F 

Table  2  Reticle  Aiming  Error  Evaluation 


To  assure  that  crews  do  not  progress  out  of  an  exercise  group 
prior  10  demonstrating  proficiency  in  the  critical  tasks  required 
ot  that  exercise  group,  the  following  special  rules  are  enforced 

•  In  each  reticle  aim  group  a  specific  exercise  at  a 
designated  position  in  the  matrix  must  be  completed  and 
the  crew  (or  commander)  must  achieve  at  least  a  normal 
advancement  recommendation  in  all  three  skill  areas 

•  A  minimum  acceptable  proficiency  level  is  established  for 
system  management  and  target  acquisition  skill  areas  dur 
Ing  the  conduct  of  exercises  with  malfunctions 

•  Crews  will  be  designated  as  certified  upon  obtaining  at 
least  a  "normal  advancement"  recommendation  in  all 
three  skill  areas  in  specific  certification  exercises  in  sus¬ 
tainment.  transition,  basic,  and  cross  training. 


Skill 

Matrix  Movement  Requirements 

Dimension 

To  Next  Higher  Level 

To  Next  Lower  Level 

To  Skip  a  Level 

Systems 

Two  or  more  successive 

Two  or  more  consecu 

T  wolevei 

Management 

"normal  advancement 

live  "reduced  recom 

increase  or 

(SM) 

recommendations  in  con 

mendations  tor  either 

decrease  is  not 

lunctron  with  a 
"normal  or  higher 
recommendation  tor  reticle 
aim  on  the  last  exercise 
fired. 

systems  management  or 
reticle  aim 

allowed 

Target 

Rapid  advancement 

Two  or  more  consecu 

Not  allowed 

Acquisition 

recommendation  for  the 

tive  reduced 

(TA) 

last  exercise  fired, 
or  two  consecutive 
"normal  advancement  oxer 
cise  recommendations 

exercise 

recommendations 

Reticle 

Normal  advancement  ' 

Not  allowed  Reduc 

Rapid  advam  emnnt 

Aim 

except  m  certain 

tion  in  systems 

» 1  x err . i se  roc om me n d a 

IRA) 

special  cases 

management  levH  is 
recommended  instead 

bon  dn  certain  special 
cases  nit  >vemont  to  the 
nr*  t  l< ’v*  •'  may  he 
r« '<  '  tmmendcdi 

Table  3.  Matrix  Movement  Rules 


£ 


'  W  *  .  " 


J0 

> ' 


ra 


K:-.: 


.*s 


,%  > 


m 


i* *  ** 

r/.v 


►  Iv 


h#: 


fe: 


fc*: 


INSTRUCTIONAL  FEATURES 


The  U-COFT  instructional  subsystem  is  characterized  by  an  ex 
tensive  range  ot  capabilities,  selectable  at  the  instructor  s  op 
tion.  that  enable  him  to  efficiently  and  effectively  control  and 
manage  the  overall  training  process.  These  capabilities,  which 
are  implemented  through  data  collection,  performance  evalua¬ 
tion  and  analysis,  and  training  management  functions  em¬ 
bodied  within  the  subsystem,  are  summarized  in  Table  4. 


Exercise  Selection 


In  the  training  mode,  exercise  selection  may  be  accomplished 
by  the  instructor  in  three  different  ways: 

•  By  computer  recommendation,  in  which  the  computer 
assesses  the  crew's  matrix  position,  evaluates  the  results  of 
computer-recommended  exercises  previously  completed,  and 
selects  the  next  exercise  for  the  crew  to  perform.  Each  train¬ 
ing  session  begins  with  the  last  computer-recommended 
crew  exercise  performed  during  the  previous  training  session; 
this  helps  account  for  any  performance  loss  since  the  last 
session.  The  instructor  can  accept  the  computer's  recommen¬ 
dation.  or  based  on  his  personal  assessment  of  crew  perfor¬ 
mance  he  may  select  an  exercise  by  content  or  by  specific 
exercise  number. 


By  exercise  content  based  on  d.-s-  up-tots  including 

ownvehicle  speed  target  type  target  . . .  initial  target 

range,  crew  member  flung  ..i-upon  c-i  non  sight  selec¬ 
tion,  visibility  conditions  and  malfunctions  Successive 
content  selection  pages  for  «..«r  h  d  the  descriptors  arc- 
presented  to  the  instructor  and  via  a  selection  try 
elimination  process,  a  listing  of  I  hose  exercises  m  the 
library  which  contain  the  selected  descriptor  elements  is 
displayed  to  the  instructor  by  exercise  number  Upon 
selection  o'  an  exercise  from  the  list,  a  'detailed  oc-sc.np 
tion  of  that  exercise  is  presented  at  the,  point  (hi  mstfin 
tor  may  opt  to  run  that  exercise  or  re-  may  seieoi  another 

By  exercise  number,  based  on  instructor  apt  ion  knowledge 
or  selection  via  bis  field  manual  which  lists  and  describes 
all  exercises  available  for  use 


Although  the  instructor  has  the  option  uf  ignonng  the  computer 
recommendation  tor  the  next  crew  or  commander  exercise  pro 
gression  through  the  matrix  will  not  be  aliened  by  his  soiec 
tion  For  example,  it  at  the  conclusion  of  an  exercise  the  com 
puter  recommends  exercise  12345  hut  I  he  instructor  decides 
to  select  exercise  98765  the  system  would  run  exercise 
‘98765 "  At  the  conclusion  ol  Hus  exercise  and  regardless  of 


FUNCTION 

PURPOSE 

RESULT  EFFECT 

Mode  control 

Select  and  terminate  specific 
operational  mode  (I.e.,  training,  training 
management,  daily  readiness  check, 
diagnostic  test). 

Mode  selected  is  executed. 

Exercise 
selection, 
preview,  briefing 

Provide  instructor  with  exercise 
description  for  briefing  to  the  crew. 

Description  of  exercise  and  initial 
tactical  environment  is  displayed  to 
instructor  after  exercise  is  selected. 

System  setup 

Perform  automatic  check  of  crew 
compartment  switch  settings  (by 
trainees)  for  correctness. 

Exercise  will  not  start  if  check  fails.  Incoirect 
settings  are  displayed  to  instructor,  who  will 
inform  crew  to  correct  settings. 

Performance 
monitoring  and 
analysis 

Convey  trainee  performance  data  to 
instructor  during  exercise,  during 
playback,  and  on  completion  of 
exercise. 

D'splays  via  situation  monitor  page: 

•  '  'rent  ballistic  computer  data 

•  .  erational  mode 

•  Current  switch  positions 

•  Current  exercise  and  situation  numbers 

•  Elapsed  exercise  time 

•  Current  and  past  engagement  data 

•  Engagement  results/scores 

Session 

summary 

Summarize  overall  crew  performance  tor 
each  training  session. 

Session  summary  is  displayed  and/or 
printed 

Shot  pattern 
(For  105  mm 
main  gun  only. 

No  shot  pattern 
for  area  fire 
weapons,  i.e.. 
coax  and  cal  .50 

Provide  graphic  view  of  shot  patterns 
for  up  to  two  rounds  per  target  in  the 
exercise. 

Shot  pattern  reflecting  hit  data  relative  to 
center  of  mass  of  the  target,  accurate  to 

0.1  mils  in  azimuth  and  0.2  mils  in 
elevation  is  printed. 

Exercise  control 

Provide  instructor  with  comprehensive 
control  ot  exercise. 

Selected  controls  are  executed. 

•  Exercise  freeze/untreeze  at  any  point. 

•  Record/playback  of  visual  scenes  and 
aural  cues  for  current  exercise  (no 
voice  communication). 

•  Exercise  repeal. 

•  Logging  of  verbal  commands  by  crew 
during  exercise  (i.e  .  gunner  iden¬ 
tified.  from  my  position,  driver 
stopiqo.  cal  50). 

•  Ammo  selection  input. 

•  Printout  of  situation  monitor,  perfor¬ 
mance  analysis,  and/or  shot  pattern 
pages 

•  Input  of  identification  (ID)  error. 

I  able  4.  Instructional  Features  Summary 
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how  well  the  crew  performed,  the  computer  would  once  again 
recommend  "12345“  as  the  next  exercise.  This  process  would 
continue  regardless  of  the  type  or  number  of  exercises  selected 
bv  content  or  number  by  the  instructor  The  intent  of  the  rule  is 
to  prevent  situations  in  which  critical  skill  elements  may  not  bo 
exercised  if  instructor  manipulation  of  crew  progress  was 
allowed,  and  to  standardize  crew  instructional  content  which 
could  be  compromised  by  instructor ,  having  different  levels  of 
skill  It  is  entirely  probable,  howe.  r.  that  by  exercising  crews  in 
specific  exercises  selected  by  content  or  by  number  the  instruc 
tor  may  bring  about  a  more  rapid  advancement  once  the  system 
and  exercise  selection  is  returned  to  the  computer. 

Performance  Monitoring 

An  instructional  feature  that  is  expected  to  be  highty  critical  to 
training  is  the  situation  monitor  page,  displayed  on  the  IOS 
display  terminal  CRT,  that  conveys  student  performance  data  to 
the  instuctor  both  during  and  immediately  after  the  exercise.  This 
page,  a  typical  example  ot  which  is  shown  in  Figure  3.  contains 
information  such  as  current  ballistic  computer  data,  operational 
modes,  current  crew  station  switch  positions,  current  exercise 
number,  elapsed  exercise  time,  current  situation  number,  current 
enemy  target  and  past  target  engagements  (in  terms  ol  weapon 
firing,  target  type,  main  gun  round  number  or  machine  guns  burst 
number,  reticle  aim  error  in  azimuth  and  elevation),  and  results 
for  the  engagement  While  the  situation  monitor  page  is  updated 
once  each  second,  aiming  errors  are  updated  as  each  round  is 
fired.  Data  for  the  current  engagement  is  highlighted  on  the 
display  to  distinguish  it  from  previous  data  and  data  for  upcom¬ 
ing  targets;  the  latter  is  listed  for  each  target  in  terms  of  seconds 
before  target  appears,  target  bearing,  and  target  type  Also  in 
eluded  is  the  situation  letter  grade  system  status  prompt,  and 
keypad  options  prompt  Letter  grades  are  interpreted  in  relation 
to  the  student  progress  recommendation:  i.e..  "A"  for  rapid  ad 
vancement.  "B"  for  normal  advancement.  C  for  no  advance¬ 
ment.  and  "F"  tot  icduction  in  standing  (regression). 

In  the  example  provided  in  Figure  3.  eight  of  the  ten  situations 
have  been  presented  to  the  crew  In  situation  No.  1.  the  crew 
engaged  a  fully-exposed  T72  target,  fired  cue  round  and  missed 
due  to  an  elevation  aim  error  of  2110  mils  low  In  situation  No 
5.  the  crew  engaged  troop  (area)  targets  with  the  coax  machine 
gun.  fired  128  rounds,  hit  38%  of  the  target  and  received  a  ’miss" 
because  75%  coverage  is  required  for  a  "kill''  In  situation  No. 
9.  a  HIND-D  helicopter  will  appear  in  35  seconds  at  a  position 
five  degrees  to  the  crew's  right.  Situation  No.  10  will  be  a  T72 
tank  which  will  appear  in  83  seconds  at  a  point  directly  in  front 
ot  the  present  viewing  point.  Additional  information  presented 


on  this  page  is  the  true  range  ot  the  target  and  the  range  input 
to  the  computer  by  the  crew's  ranging  to  the  target,  the  mode 
of  operation  is  normal  mo  malfunctions),  laser  is  set  to  First 
Return,  the  gunner  has  mam  weapon  selected  and  SABOT  index 
ed.  SABOT  is  loaded  All  of  this  dala  is  available  to  the  instruc 
tor  and  is  updated  in  real  time  He  may  use  .1  to  cue  or  assist 
the  crew,  or  not.  as  he  sees  tit 

Exercise  Control/Monitoring 

The  instructor  utilizes  dedicated  keys  on  a  VT-102  auxiliary 
keypad  to  control  the  exercises  and  the  overall  conduct  of  the? 
training  session  The  auxiliary  keypad,  shown  in  Figure  4.  allows 
the  instructor  to  accomplish  the  following  functions 
•  Freeze  Unfreeze  Interrupt  an  exercise  at  any  point  in  its 
execution  and  resume  the  exercise  at  the  point  of  interrup¬ 
tion  At  this  point  the  instructor  may  critique  the  crew  and 
then  proceed;  repeat  the  e;  erase  from  the  beginning; 
playback  all  or  part  of  the  exercise;  terminate  the  exercise, 
display  the  performance  analysis  page  at  the  situation 
monitor;  or  print  the  shot  pattern 


Figure  4.  IOS  VT-102  Terminal  Keyboard  Arrangement 
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•  Record-Playback  Playback  all  nr  ; , t ;  ,r  tt--  r ,t  ! 

minutes  ot  all  of  the  visual  .nut  ,«umI  -■.■■n".  •  it,,,;  - 

cise  period 

•  Exercise  Repeat  Repeat  the  selected  ",  a  pi. 

beginning 

•  Command  Logging  The  instructor  v.an  uki  ..m  u  .  .•••:  ■ 
identification  commands  try  tile  ere  a  rp.-mp..",  diiiin;  t’v- 
conduct  ot  an  exercise  These  include 

—  Identified  tgunnei  responsoi 
—  From  my  Position  icomnumdi  i  ies|  omsi-i 

-  Driver  STOP'GO  In  this  way  the  instru  tor  acts  as  lh. 
driver  to  move  the  tank  to  and  from  de-fnade.  or  K  hall 
and  resume  movement  in  a  moving  oxer-  tse 

-  Cal  50 

•  Ammo  Selected  Keys  -  The  instructor  may  act  as  the  load.  1 
by  pressing  either  the  APDS,  HEAT,  or  HEP  keys  ■/.hen  the 
tank  commander  announces  the  round  type 

•  Reload  Key  Removes  round  currently  in  the  breech  and 
reloads  a  different  type  round  if  so  designated  by  the  tanl 
commander  A  suitable  delay  is  initiated  before  the  next 
round  can  be  fired. 

•  Print  ■  Will  print  situation  monitor  or  performance  analysis 
page  as  selected. 

•  Print  Shot  Pattern  ■  Prints  page  containing  shot  patterns 
for  up  to  two  main  gun  rounds  for  each  target  in  the  exer 
cise  This  pattern  will  reflect  the  reticle  lay  error  for  each 
round  Indicator  to  an  accuracy  of  0.1  mil  in  azimuth  and  0.2 
mil  in  elevation. 

•  ID  Error  -  Allows  the  instructor  to  assess  a  penalty  against 
the  crew  if  an  improper  target  identification  has  been 
made. 


The  U  S  Army  is  closely  monitoring  the  development  of  voice 
recognition  technology  with  an  eye  toward  utilizing  this  techni¬ 
que  to  accomplish  some  or  all  of  the  instructor  monitoring 
noted  above  Exploratory  evaluation  of  existing  voice  recogni¬ 
tion  systems  has  shown  that  U-COFT  need.j  for  connected/con¬ 
tinuous  voice  recognition  cannot  be  fulfilled  at  present 
However,  the  software  currently  used  tor  implementing  tne 
various  keyboard  functions  is  designed  to  easily  accept  the  ad 
dition  of  voice  recognition  when  such  technology  is  sufficiently 
advanced  to  warrant  it. 
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ABSTRACT 

A  current  DOD  thrust  to  develop  and  apply  modularity  approaches,  tools  and  standards  to  training  simulator  di'.t-  ■  1 

and  acquisition  is  expected  to  yield  benefits  in  reduced  cost  and  acquisition  time  as  wen  as  improved  suppodabmly 
Top-down  lunctional  design  ot  stand  alone  modules  and  well-detmed  interlaces  wilt  enhance  simulator  system  designs  This 
paper  examines  the  effects  and  benefits  of  modularity  which  are  expected  to  increase  readiness  through  nanie'  t'ame' 
availab  Hy  dates  and  increased  supportability  The  derivative  etlecl  of  modularity  appears  to  provide  new  options  that  can 
operate  to  support  increased  defense  readiness. 


INTRODUCTION 

The  U  S  Government  has  recently  launched  a  modular  simulator 
design  development  program  The  present  effort  locuses  on  aircrew 
training  simulators.  Several  factors  and  considerations  appear  to  have 
influenced  this  initiative 

Empnasis  on  ground-based  training  for  the  full  military  aircrew 
complement  has  led  to  the  development  of  complex  training  systems 
In  turn,  technical  and  management  challenges  for  procuremeni 
agencies,  and  the  simulation  industry  have  resulted,  such  as 

•  Trainers  cost  more  than  expected 

•  Trainers  take  longer  to  develop  than  expected 

•  Trainer  supportability  does  not  meet  expectations 

Seeking  ways  to  meet  these  challenges  and  in  light  of  the  success 
of  the  Ae  Forces  Modular  Automatic  Test  Equipment  (MATE) 
program,  a  government  decision  was  made  to  investigate  the 
advantages  of  modularizing  simulators  starting  with  aircrew  trainers 
DOD  procures,  operates  and  supports  a  large  number  and  a  wide 
variety  of  training  equipment  and  could  conceivably  benefit  from  the 
establishment  of  modularity  standards  Envisioned  is  a  program 
conceptually  similar  to  the  current  MATE  program.  Potential  benefits 
include: 

•  Reduced  cost 

•  Reduced  development  time 

•  Improved  supportability 

•  Improved  modification  capability 

If  these  benefits  are  realized  with  the  eventual  development  and 
application  of  modular  simulator  design  standards  across  industry, 
then  it  appears  likely  that  another  important  benefit  will 
result — defense  readiness  will  be  increased 

As  an  example,  in  a  related  program  the  readiness  benefit 
envisioned  by  the  contractor  responsible  for  the  MATE  program  was 
that  the  defense  mission  is  better  fulfilled  through 

•  Simpler  skills  and  training  because  of  computer-simplified  lest 
procedures,  common  hardware,  procedures,  and  documentation 

•  Reduction  of  false  reacts 

•  Eliminating  unnecessary  troubleshooting 

These  benefits  are  for  MATE  but  do  indicate  general  readiness 
improvement  potential  for  application  ot  modular  principles  to 
simulator  development 


DEFINITION  OF  TERMS 

Modular  simulator  design  or  modularization  is  defined  as  me 
organization  of  subsystern/hardwarelsoftware  components  into 
standard  units  This  involves  breaking  me  (light  simulator  package 
down  into  cohesive  blocks  (modulesi  of  equipment  or  software  with 
standards  lor  control  of  design  and  acquisition  of  the  modu'es  Using 
this  approach  any  number  of  modules  can  be  readi'y  integrated  to 
form  a  new  simulator,  thereby  using  known  hardware  and  software 
with  performance  results  predictable  in  advance 

Readiness  is  a  complex  term  and  implies  different  things  unde' 
different  conditions  For  our  present  purpose,  readiness  is  defined  as 
the  slate  of  being  prepared  and  able  to  do  the  assigned  mission 
without  serious  limitations  That  is  whatever  the  organizational  level 
or  military  service,  the  equipment  is  ready  the  crews  are  trained  and 
the  logistics  support  is  available  There  are  states  of  readiness  such 
as  day-to-day  readiness  and  crews  sitting  on  the  runway  There 
are  levels  of  readiness  such  as  employed  by  SAC  But  what  we 
basically  mean  by  readiness  is  ready  and  able 

ANALYSIS  OF  MODULARIZATION  BENEFITS 

What  usually  motivates  investment  of  time,  energy  or  money  is  the 
potential  payoff  We  can  better  visualize  this  payoff  for  the  eventual 
application  of  the  modular  simulator  design  approach  as  shown  in 
Figure  1  That  such  benefits  can  be  realized  from  using  the 
modularization  approach  is  supported  by  the  relative  benefits 
achieved  from  modularization  in  an  Automatic  Test  Equipment  t ATE ) 
product  line,  as  shown  in  Figure  2 


Figure  1  Relative  Benefits  of  Modular  Simulator 

Design  Approach  Application  (Conceptual) 

The  favorable  influence  that  modularization  ot  Laming  simulators 
could  have  on  readiness  is  shown  m  Fiaiae  3  However  modm.i' 
simulator  design  does  not  automatically  buy  unproved  readiness  To 
realize  such  improvements  win  require  some  consideration  tor  lacto's 
that  link  potential  modularity  benefits  with  readiness  improvements 
This  consideration  will  involve  both  the  government  and  industry  T  o 
illustrate:  The  involvements  and  benefits  expected  from  the  MATt 
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Figure  2  Relative  LCC  Comparison  of  Modular  vs 
Standard  ATE  Design 
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Figure  3  Modular  Simulator  Benefits  Lead  to  Options 
Having  Potential  Impact  on  Readiness 

program  is  exemplified  in  a  1980  AIAA  paper  by  WPAF8  logisticians. 
LI.  Col  Byrne  and  Cap!  Allen,  where  they,  in  pari,  conclude: 


"MATE  can  make  affordable  automatic  testing  a  reality  for  the 
Air  Force  and  offers  numerous  collateral  benefits  However, 
standardization,  especially  during  this  transition,  will  not  come 
easily."1” 


These  authors  enumerate  many  expected  benefits  from  the  point  of 
view  of  government  and  commercial  developers,  the  military  user,  and 
the  logistics  supporter.  In  order  to  see  the  origin  and  sequence  ot  the 
development  of  benefit  options  better,  we  will  next  look  at  one 
approach  to  the  modular  simulator  design  concept  development 
program. 


MODULAR  SIMULATOR  DESIGN  APPROACH 

This  approach  employs  a  disciplined  systems  engineering  structure 
to  take  full  advantage  ot  the  value  of  this  process  as  a  means  of 
providing  an  unbiased,  logical  framework  (or  conducting  the  modular 
simulator  design  concept  definition  (Figure  4)  The  approach  is 
divided  into  five  broad  functional  areas  (Figure  5): 

•  Design  concept  definition 

•  Design  concept  application 

•  Impact  definition 

•  Implementation  planning 

•  Concept  documentation 
Design  Concept  Definition 

The  concept  definition  begins  with  a  top-down  functional  analysis 
that  considers  existing  functional  groupings,  identifies  operational 
performance  requirements  and  determines  the  specific  capabilities 
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needed  to  satisfy  the  functional  requirements  The  oulpui 
representing  an  aircrew  simulator  functional  analysis,  is  utilized  to 
formulate  the  preliminary  modularity  concept  in  concert  with  the  initial 
module  selection  criteria  Special  emphasis  is  placed  on  the  resolution 
ot  hardware/software  module  levels  lhat  meet  the  functional 
performance  requirements  yet  minimize  any  effects  of  modularity  on 
technological  innovation  and  development 

Design  Concept  Application 

The  preliminary  module  selection  criteria  developed  during  design 
concept  definition,  is  applied  to  selected  Weapon  System  Trainer 
(WST)  programs  to  provide  additional  design  insights  and  validation 
opportunities.  The  physical  and  functional  interlace  definition  is 
explored  in  terms  of  establishing  a  concept  that  will  standardize  and 
simplify  both  the  physical  and  functional  aspects  of  a  modular  design 
The  preliminary  output  is  tested  by  further  application  ot  these 
concepts  to  the  selected  WST.  In  addition,  an  existing  set  of  physical 
functional  interface  criteria,  developed  in  support  ol  ongoing  company 
modularity  research  and  development  programs,  serves  to  further 
refine  the  candidate  approaches  for  an  industry-wide  application 

Impact  Definition 

During  impact  definition,  the  impact  on  module  testing/qualification 
Higher  Order  Language  (HOL).  logistics,  aircraft  equipment  and 
existing  simulator  modularity  elements  are  assessed  Knowledge  ot 
military  systems  and  proven  logistics  models  are  applied  toward  an 
obiective  evaluation  of  the  modularity  impacts.  This  approach  to 
module  testing  and  qualification  is  relined  through  development  of  a 
list  of  requirements  based  on  the  final  selection  criteria  and  the 
selected  interface  approach  Development  ot  implementation  tools 
parallels  this  activity.  The  output  is  a  plan  that  clearly  defines  the  path 
to  module  qualification  An  assessment  ot  the  interrelationships 
between  the  modularity  concepl  and  related  support  elements  is 
conducted  with  impacts  being  defined  and  quantified  in  terms  ol  cost, 
availability  and  manpower.  Additional  impact  assessments  are 
conducted  relative  to  the  use  of  HOL  and  Ada  languages  on  military 
simulators  Cost  data  generated  in  the  preceding  areas  is  used  to 
assess  the  impact  of  the  modularity  concept  on  aircraft  equipment  and 
the  results  quantified  in  terms  ol  capabilities  which  may  be  built  into 
aircraft  systems  to  support  simulator  modularity  as  well  as  any  impact 
on  acquisition  and  life  cycle  costs 

Implementation  Planning 

Recognizing  that  the  success  of  the  simulator  modularity  concept  is 
dependent  on  an  effective  and  appropriate  management  system, 
planning  Is  developed  that  establishes  a  viable  schedule  for 
phase-in/out  of  simulator  modules/standards,  the  required 
managemenl  structure  and  modularity  tools  Close  coordination  with 
the  government  is  imperative  in  this  process  Implementation  costs 
are  developed  using  proven  cost  estimating  methods  for 
development,  production,  and  operations  and  support  elements.  A 
follow-on  phase  plan  is  to  be  developed  to  provide  for  the  redesign  of 
an  existing  simulator,  testingfqualifications  of  the  resulting  modules, 
integration  of  modules  into  a  training  system  and  validation  of  the 
modularization  tool  system  performance. 

Concepl  Documentation 

As  the  final  action,  a  technical  report  is  prepared  which  will  present 
a  complete  and  comprehensive  documentation  of  the  modularity 
approach.  This  report  includes  statement  ot  work  and  associated 
specifications  as  well  as  the  procedures,  processes  and  rationale 
used  in  conducting  a  follow-on  study 

ANALYSIS  OF  AIRCREW  TRAINING  SIMULATOR  FUNCTIONS 

System  engineering  techniques  and  procedures  are  used  to 
conduct  a  top-down  functional  analysis  ot  aircrew  training  simulators 
Existing  functional  grouping  concepts  used  in  all  levels  of  training 
devices  are  considered  during  this  analysis  However,  these  grouping 
and  module  concepts  are  not  considered  as  constraints  on  the 
functional  analysis.  For  example.  Figure  6  illustrates  two  potential 
modularity  approaches  to  a  given  aircraft  multifunction  training 
application. 
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The  first  approach  is  representative  of  current  training  simulation 
technology.  In  this  approach  ma|Or  system  modules  perform  common 
simulation  tasks  across  all  simulated  aircraft  functions  Computational 
processing  and  hardware/software  interface  equipment  are  treated  as 
major  system  modules.  Individual  software  and  hardware  modules  at 
a  lower  level  simulate  the  aircraft/system  functions 

An  alternative  approach  might  involve  modularization  by 
aircratUsystem  function.  In  this  approach,  all  necessary  processing 
hardware  and  software,  interface  and  control/display  capability  for  a 
particular  subsystem  would  be  contained  within  a  given  function 
module.  In  this  case,  it  would  be  extremely  important  to  identify  and 
specify  a  flexible,  common  interface  to  communicate  between  system 
modules  In  current  applications,  visual.  DRLMS  and  motion  systems 
lend  themselves  well  to  modularization  at  this  level  Extension  of  this 
type  of  function/module  allocation  *o  other  training  subsystems  such 
as  instructional,  environmental  and  aircraft  systems  simulation  are 
considered 

Operational  performance  requirements  for  military  training 
simulators  are  identified,  including  the  support  requirements 
necessary  to  maintain  the  operational  capability  of  these  systems 
Operational  constraints  are  also  defined  This  analysis  determines 
how  each  function  is  performed  and  considers  feasible  alternate 
combinations 

Capabilities  required  to  satisfy  identified  functional  requirements 

are  determined  by 

•  Examining  each  system  function  to  determine  the  kinds  of 
capabilities  needed  to  meet  training  simulator  performance 
requirements 


•  Exploring  possible  combinations  of  functions  which  provide  the 
required  performance  capability,  while  simplifying  the  interface 
complexity. 

Potential  modules  and  functional  groups  of  modules  are  then 
allocated  to  the  identified  functions  and  required  capabilities  A  similar 
process  was  followed  in  using  MATE  guides  to  simplify  interfaces  as 
those  shown  in  Figure  7. 


Figure  7  MATE  Standard  Interfaces 
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CANDIDATE  MODULE  GROUPING 


Candidate  groupings  of  potential  modules  are  prepared  from  the 
aircrew  simulator  functional  analysis  previously  discussed  These 
candidate  groupings,  taken  from  a  cross  section  of  simulation  and 
aircraft  industries  are  documented  in  terms  of  functional  capability  and 
interface  descriptions  Examples  of  the  results  of  such  groupings  are 
shown  in  Figure  8  for  a  flight  crew  trainer.  Development  of  the 
candidate  groupings  goes  hand-in-hand  with  development  of  the 
candidate  levels  discussed  in  the  subsequent  section. 

Sensor  simulation  systems,  such  as  visual  Computer  Image 
Generation  (CIG)  and  Digital  Radar  Land  Mass  Simulation  (DRLMS] 
systems,  provide  good  examples  of  potential  candidate  modules 

Sensor  simulations  incorporate  Digital  Data  Bases  (DDBsi  which 
provide  a  processor-compatible  earth  topography  model  to  be  used  in 
generation  of  simulated  visual/sensor  imagery  Historically  these 
DDBs  have  been  quite  different  between  suppliers  and  even  between 
the  individual  sensor  simulation  types  of  a  particular  contract  This  has 
been  due  primarily  to  the  fact  that  DDBs  were  a  result  and  not  a 
requirement  of  the  sensor  simulation  design  process 

Improvements  to  digital  processing  state-of-the-art  have  removed 
many  of  the  constraints  on  sensor  simulation  processing,  raising  the 
possibility  that  the  DDB  could  become  the  standard  component  or 
module  around  which  new  CIG.  DRLMS  and  other  sensors  are 
designed  Figure  9  shows  a  potential  approach  whereby  an  integrated 
data  base  generation/support  system  could  be  employed  to  support  a 
number  of  sensor  simulations 

A  modularity  approach  whereby  the  DDB  is  considered  a  standard 
"module  "  may  provide  both  training  fidelity  and  supportability  benefits. 
Since  the  DDBs  for  these  simulations  provide  real-world  terrain 
references  and  since  multiple  sensor  simulations  may  be  active 
simulataneously.  this  approach  would  provide  a  high  degree  of 
correlation  between  the  individual  simulations.  Additionally,  the 
necessity  to  create,  maintain  and  support  a  number  of  separate  DDB' 
would  be  reduced  or  eliminated 

In  this  example,  it  is  important  to  note  that  any  standardization  of  the 


DDB  would  have  to  be  carefully  applied  to  data  base  content  and 
format  and  not  to  specific  media  Advancement  in  lase' -optical 
bubble  memory  and  other  high  density  bulk  memories  would  quickly 
cause  the  obsolescence  of  any  media  standardization  Sensor 
simulation  systems  present  other  possibilities  for  modularity  beyond 
the  DDB  since  processing  subsystems  such  as  line  of  sight 
coordinate  transformation,  data  retrieval  and  memory  management 
subsystems  perform  largely  Ihe  same  function  regardless  of 
application. 

MODULAR  LEVEL  DEFINITION 

Development  of  the  candidate  levels  is  an  iterative  process  which  is 
initially  derived  from  the  top-down  CWBS  examination  of  the  typical 
trainers  in  conjunction  with  the  functional  analysis  of  the  natural 
interface  groupings  However,  the  ultimate  definition  of  the  modularity 
levels  comes  concurrently  with  the  definition  of  Ihe  modules 
themselves  through  repeated  refinement  and  application  of  the 
module  selection  criteria  Two  considerations  in  level  selection 
discussed  here  are  (1)  future  industry  innovation  impact  and  i?| 
module  complexity 

Innovation  Impact 

The  interplay  between  a  specific  modularization  concept  and  future 
technological  innovation  is  a  subject  requiring  special  emphasis  and 
insight.  In  most  areas  of  technology  the  simulator  .ndustry  uses  the 
latest  state-of-the-art  techniques  and  will  probably  continue  to  do 
so:  however,  the  industry  is  not  generally  m  itself  a  significant 
technology  driver  The  only  major  exception  is  that  of  sensor  system 
(visual/digital  radar  landmass  simulation)  in  which  new  techniques 
such  as  laser  scanners  are  under  development.  If  modularity  is 
standardized  incorrectly,  the  ability  of  industry  to  use  state-of-the-art 
innovations  will  be  inhibited  Ideally,  from  an  innovation  viewpoint,  the 
modular  simulator  design  concept  should  standardize  interfaces  but 
allow  total  freedom  of  design  within  the  module.  If  the  standardization 
■J  dates  the  internal  design  of  the  ERU.  innovation  flexibility  is  lost.  It 
.  •  pears  that  the  most  important  level(s)  at  which  to  apply  the 
innovation  freedom  is  a  combination  of  the  system  level  and  the  ERU 
level 


Figure  8  Flight  Crew  Trainer  Module  Grouping  Example 


Figure  9  Data  Base  Driven  Sensor  Simulation  Example 
Module  Complexity 


Module  levels  are  also  resolved  in  light  of  both  hardware  and 
software  complexity  needed  to  meet  the  functional  performance 
requirements.  For  example,  if  trainer  A  requires  only  50  percent  of  the 
performance  capability  of  trainer  B  in  a  particular  module  or  module 
grouping,  does  trainer  A  pay  the  overhead  of  carrying  the  additional 
capability  for  the  sake  of  standardization  or  go  to  the  next  lower  level 
and  still  select  standard  modules  to  provide  the  required  level  of 
capability?  An  example  of  software  levels  is  provided  in  Figure  10 


Figure  10  Example  of  Computer  Program  Modularity  Levels 


OTHER  MODULE  DEVE1  OPMENT  CONSIDERATIONS 

The  purpose  of  this  paper  and  space/time  limitations  do  not  allow  a 
full  description  of  the  process  of  development  of  the  modular  simulator 
design  approach  However,  this  approach  includes 

•  An  industry  survey 

•  Implementation  tools  definition 

•  Module  selection  criteria  development  and  use 

•  Modular  design  concept  applications 

•  Logistics  considerations 

•  Development  and  validation  of  modular  simulator  design  tools 

Now  that  we  have  reviewed  an  approach  to  the  development,  and  to 
some  extent,  the  application  of  modular  simulator  design  concepts, 
we  have  a  better  foundation  to  visualize  how  modularization  benefits 
can  be  linked  to  readiness 

ANALYSIS  OF  MODULARITY/READINESS  RELATED  BENEFITS 

Some  modular  simulator  design  application  benefits  may  well 
provide  fallout  readiness  benefits  without  specific  plans,  decisions,  or 
actions.  We  can  be  satisfied  with  that,  or  we  can  thoroughly  analyze 
all  potential  links  between  modularization  and  readiness  benefits  and 
plan  to  enhance  the  value  of  simulator  modularization  benefits  that 
improve  readiness.  The  key  is  to  recognize  the  improved  (or 
increased)  decision-making  options  in  working  alternatives  For 
example,  in  Figure  3  if  the  sought  benefit  of  reduced  cost  is  realized 
this  leads  to  an  "available  funds"  option.  These  would  be  government 
funds  that  could,  by  decision,  be  left  unused  or  used  for  any  other 
purpose  within  the  fiscal  constraints  In  this  case,  the  only  way  to 
enhance  readiness  is  to  reallocate  saved  funds  to  a  readiness  cause 
A  second  example  from  Figure  3  is  the  earlier  delivery  of  training 
simulator  option  which  is  possible  when  development  time  of  a 
simulator  is  reduced  through  modularization  If  this  benefit  is  expected 
and  the  decision  is  made  to  start  the  training  simulator  development 
later,  by  the  number  of  months  saved,  then  of  course  the  modularized 
simulator  trainer  would  be  delivered  at  the  same  time  as  the 
unmodularized  simulator  trainer,  and  there  would  be  no  beneficial 
impact  on  readiness  from  that  modularization  benefit  The  point  is. 
that  only  if  the  appropriate  decision-makers  are  aware  that  such 
options  exist  and  that  there  is  a  plan  in  effect  that  states  a  requirement 
to  weigh  such  factors  in  their  decision-making  consideration  will  some 
potential  readiness  benefits  be  able  to  be  realized  from 
modularization 

On  the  whole  the  derivative  effects  of  modularity  appears  to  provide 
new  options  that  can  (or  can  be  made  to)  operate  to  support  increased 
defense  readiness 

REFERENCES 

1.  Byrne.  R  O  and  M  K  Allen  Affordable  Automatic  Testing 
AIAA-80-1826,  AIAA  Aircraft  Systems  Meeting  August  4-6 
1980.  Anaheim.  CA 

ABOUT  THE  AUTHOR 

Mr  Frederic  W  Snyder  is  a  Training  Equipment  Engineer  in  the 
Military  Training  Systems  organization  of  the  Boeing  Military  Airplane 
Company.  Wichita.  Kansas.  He  is  currently  performing  system  studies 
in  the  new  business  area  He  has  a  Master  s  degree  in  Experimental 
Psychology  from  Wichita  State  University  He  has  served  as  a 
Research  Specialist  and  Senior  Supervisor  in  Crew  Systems  In  these 
capacities  he  has  participated  in  and  directed  Crew  Systems 
Engineering  and  Simulation  programs  as  part  of  military  airplane 
development  and  R&D  at  Boeing  for  25  years  Prior  to  joining  Boeing 
he  was  Staff  Research  Psychologist  at  the  Menmnger  Foundation  and 
an  instructor  in  Psychology  at  Wichita  State  University  Mr  Snyder 
has  published  and  presented  a  number  of  research  papers  in  the  field 
of  psychology  and  crew  systems,  authored  a  book  chapter  on 
vibration  and  vision,  and  co-authored  a  book  on  inverted  vision 
research 


334 


AD-P003  492 


A  FOUR-DIMENSIONAL  THUNDERSTORM  MODEL  FOR  FLIGHT  SIMULATORS 
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ABSTRACT 

The  recent  airliner  crash  at  New  Orleans  indicates  that  windshears  due  to  thunderstorm 
downbursts  challenge  the  most  experienced  and  well-trained  pilots.  Much  controversy  exists 
as  to  the  correct  flight  procedures  for  takeoff  and  landing  under  downburst  windshear  con¬ 
ditions.  Flight  simulators  provide  a  safe  environment  to  test  procedures  and  train  pilots 
for  hazardous  flight  situations,  but  in  the  past,  flight  simulators  have  been  unable  to  real - 
istically  duplicate  the  complex  changes  that  occur  temporally  and  spatially  in  real-world 
thunderstorms.  A  thunderstorm  model  based  upon  real-world  data  has  now  been  developed  for 
flight  simulators,  which  provides  twelve  meteorological  flight  parameters  which  change  in 
three-dimensional  space  and  over  a  thirty-minute  time  span  with  color  weather  radar  represen¬ 
tations  of  the  storm  coordinated  in  time  and  space.  The  storm  data  set  (representing  a  20nm 
x  20nm  x  3200-ft  volume)  is  based  upon  multiple  Doppler  radar  analyses  of  a  1978  Illinois 
thunderstorm.  This  data  has  been  supplemented  by  a  well -documented,  fine  resolution,  down- 
draft  model  to  provide  realistic  values  in  the  hazardous  regions  of  the  sudden  downdraft  and 
its  resulting  turbulent  gust  front.  By  selecting  different  downdraft  intensities  and  storm 
translational  speed,  the  instructor  may  simulate  a  mild  thunderstorm  or  one  in  which  it 
would  be  impossible  to  fly.  By  positioning  the  storm's  downdraft  with  respect  to  the  runway 
in  time  and  space,  numerous  different  thunderstorm  situations  may  be  simulated.  This 
thunderstorm  model  represents  a  breakthrough  in  the  simulation  of  the  storm  environment  and 
four-dimensional  windshear  effects  for  flight  simulation. 


INTRODUCTION 

Weather  remains  an  unknown  factor  at  all 
levels  of  aircraft  operations,  from  the  military 
to  general  aviation.  Aircraft  accidents  result 
from  many  contributing  factors,  but  over  50  per¬ 
cent  of  commercial  aircraft  accidents  are 
weather-related.  Accidents  continue  to  occur 
despite  many  recent  technological  advances  in 
storm  detection  equipment  and  despite  increased 
knowledge  of  hazardous  flight  conditions, 
especially  around  thunderstorms.  Pilots  have 
generally  gained  knowledge  of  hazardous  weather 
conditions  through  actual  flight  experiences 
rather  than  through  flight  simulator  experi¬ 
ences,  because  of  the  inadequacies  of  older 
simulators  in  portraying  real-world  weather 
effects. 

Flight  simulators  have  provided  a  safe  envi¬ 
ronment  for  pilot  training  in  many  hazardous 
situations,  such  as  an  engine  out  on  takeoff  or 
a  blown  tire  on  landing,  and  have  also  been  used 
to  help  determine  correct  flight  procedures  for 
such  emergency  situations.  Flight  simulators 
might  be  used  to  unravel  the  mysteries  of  recent 
accidents  such  as  Eastern  66  at  JFK  or  Pan  Am 
759  at  New  Orleans,  In  which  windshear  may  have 
worked  in  concert  with  heavy  rain  to  produce 
aerodynamic  penalties.  Flight  procedures  in 
downburst  windshear  situations  are  presently 
being  reviewed  in  light  of  information  from 
investigation  of  recent  crashes.  But  simulators 
could  provide  false  training  if  inadequate  or 
incomplete  data  has  been  used  in  modeling  the 
hazards. 

Real-world  meteorological  data  at  the  time 
of  aircraft  accidents  is  always  sketchy  and  in¬ 
complete  since  it  is  derived  primarily  from 
flight  recorder  data  in  which  separation  uf 
weather  effects  from  pilot  effects  on  the  re¬ 
corded  motion  of  the  aircraft  is  difficult. 


Precipitation  rates  are  usually  estimated  from 
cockpit  voice  recorder  sounds,  occasional  eye¬ 
witness  accounts,  and  very  coarse  resolution 
ground  weather  radar  returns.  The  coordination 
in  time  and  space  of  the  many  weather  effects  is 
difficult  to  verify,  yet  this  is  the  primary 
type  of  data  that  has  been  available  for  imple¬ 
mentation  in  flight  simulators.  Thunderstorm 
windshears  are  very  complex,  yet  most  thunder¬ 
storm  simulations  have  consisted  of  one-dimen¬ 
sional  data  along  fata)  flight  paths. 

The  recently  developed  multiple  Doppler  radar 
techniques  have  begun  to  unlock  our  understanding 
of  the  complex  internal  circulations  of  thunder¬ 
storms.  By  combining  the  radial  wind  components 
from  two  or  more  Doppler  radars  which  are  scan¬ 
ning  the  same  storm  volume  from  different  per¬ 
spectives,  computer  analysis  may  yield  three 
time-variant  wind  components  at  every  grid  point 
(typically  0.8  km).  Meteorologists  use  these 
winds  to  extend  their  knowledge  of  the  thermo¬ 
dynamic  forcing  of  thunderstorm  circulations. 
Simulators  could  use  this  data  to  help  train 
pilots  about  thunderstorms. 

BACKGROUND 

The  complexities  of  thunderstorms  present  a 
substantial  challenge  to  the  training  and  simu¬ 
lation  community.  The  thunderstorm  is  a  dynamic, 
highly  variable  entity  which  translates  rapidly 
across  the  ground  while  growing  and  decaying 
vertically  and  horizontally,  resulting  in  con¬ 
stantly  changing  internal  and  external  charac¬ 
teristics. 

Even  the  simplest  thunderstorm,  the  airmass 
thunderstorm,  goes  through  a  series  of  stages 
during  its  20-  to  40-minute  life  span  (Figure  1). 
During,  the  initial,  or  cumulus,  stage,  the  storm 
consists  primarily  of  a  warm,  moist  updraft  in 
which  cloud  droplets  grow  into  supercooled  rain- 


drops  as  they  are  swept  up  beyond  the  freezing  have  been  well  studied  t>y  federally  funded  re¬ 
level.  As  the  raindrops  grow  too  large  to  be  search  projects  which  use  ground-based  meteoro- 

supported  by  the  updraft,  they  fall  and  drag  the  logical  networks  in  conjunction  with  research 

air  along  to  produce  a  strong  downdraft,  charac-  aircraft  and  multiple  Doppler  radars.  But  these 

teristic  of  the  mature  stage.  As  drier  outside  storms  are  so  large  and  infrequent  that  most  area 

air  is  entrained,  it  is  cooled  by  the  evaporating  airports  would  have  already  been  closed  to  air 

raindrops,  strengthening  the  downdraft  and  pro-  traffic, 

ducing  strong  winds  and  heavy  precipitation  at 

the  surface.  During  the  dissipating  stage  the  The  innocuous  appearing  thunderstorm  can  also 

downdraft  becomes  more  extensive,  the  updraft  is  provide  very  hazardous  situations  for  an  aircraft 

shut  off,  and,  as  the  storm  begins  to  self-  on  takeoff,  approach,  and  landing.  Heavy  rain 

destruct,  the  precipitation  soon  ceases  and,  produces  severely  limited  visibility,  while 

afterwards,  the  cloud  itself  begins  to  dissipate.  strong  windshears  and  turbulence  challenge  the 

flight  crew  during  very  critical  periods  of 
decision-making.  The  thunderstorm  downdraft  (or 
If  the  winds  surrounding  the  storm  permit,  a  more  severe  downburst  or  microburst)  spreads  out 

thunderstorm  may  become  better  organized  by  sepa-  near  the  ground  to  produce  a  turbulent  gust  front 

rating  the  updraft  from  the  downdraft,  resulting  which  can  extend  10  to  15  nautical  miles  away 

in  storms  that  may  last  4  to  6  hours.  These  from  the  precipitation  area  (Figure  2).  Strong 

more  severe  thunderstorms  usually  consist  of  vertical  and  horizontal  windshears  and  turbulence 

more  than  one  updraft  and  downdraft  pair,  and  are  created  as  each  heavy  rain  episode  produces 

often  occur  in  a  line  or  group  of  similar  thun-  a  surge  in  the  gust  front, 

derstorms.  A  severe  thunderstorm  may  produce 

hail  and  very  strong  surface  winds,  even  a  tor-  Thunderstorms  develop  very  quickly  under  op- 

nado.  The  supercell  thunderstorm  may  last  5  or  timum  conditions  and  can  produce  rapidly  changing 

more  hours  and  produce  large  hail  and  multiple  local  effects.  The  innocent  little  shower  that 

tornadoes.  The  largest  and  most  hazardous  storms  occurred  at  the  loading  dock  may  have  developed 


Figure  1  SCHEMATIC  DESCRIPTION  OF  THE 
THREE  STAGES  OF  THE  LIFE  CYCLE  OF  A 
TYPICAL  AIRMASS  THUNDERSTORM 
(Adpated  from  "The  Thunderstorm,” 
U.S.  Government  Printing  Office,  1949.) 


Figure  2  SCHEMATIC  DESCRIPTION  OF  A 
THUNDERSTORM  GUST  FRONT 
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a  strong  downburst  during  the  taxi  to  the  end  of 
the  runway.  As  an  aircraft  begins  its  takeoff 
roll  a  strong  gust  front  could  be  moving  across 
the  far  end  of  the  runway.  A  realistic 
thunderstorm  simulation  needs  to  account  for 
these  very  localized  and  dynamically  changing 
characteristics. 

Real-world  thunderstorms  are  highly  varied 
and  any  simulated  thunderstorm  must  provide 
enough  variability  to  provide  a  challenge  to  a 
pilot's  recall.  At  the  same  time,  maximum  train¬ 
ing  usage  requires  a  high  degree  of  repeatabil¬ 
ity,  especially  if  the  simulation  is  being  used 
as  part  of  a  pilot's  certification.  The  FAA,  as 
part  of  its  Phase  III  simulation  certification, 
has  required  that  certain  weather  effects  be  dis¬ 
played  visually  and  aurally  and  on  weather  radars 
used  as  part  of  a  pilot's  navigational  instru¬ 
ments. 

As  in  any  simulation,  all  the  visual,  aural, 
and  motion  cues  must  be  fully  coordinated  or 
false  training  will  occur,  but  few  simulator 
instructors  have  the  meteorological  training  to 
control  the  correct  timing  of  the  many  thunder¬ 
storm  effects.  Instructors  should  be  allowed  to 
concentrate  on  supervising  the  training  session 
rather  than  being  burdened  by  a  complicated 
series  of  tasks  to  create  the  effects  desired. 

For  example,  an  instructor  should  just  select  a 
weather  radar  display  of  a  thunderstorm  without 
concern  that  the  radar  echo  will  initially  appear 
at  the  correct  altitude  and  grow  vertically  and 
horizontally  in  coordination  with  the  changing 
updraft  structure.  Yet  instructors  need  to  have 
overall  control  of  storm  selection,  initial  loca¬ 
tion,  movement,  development  stage  and  intensity, 
all  of  which  must  remain  within  typical  real- 
world  thunderstorm  values. 

Now  a  thunderstorm  simulation  model  has  been 
developed  which  can  realistically  duplicate  real- 
world  thunderstorm  characteristics  important  to 
flight  training  and  which  can  meet  the  training 
requirements  of  instructor  control  of  repeat¬ 
ability  and  variability.  This  is  a  terminal 
area  thunderstorm  simulation  suitable  for  FAA 
Phase  II,  III,  and  LOFT  applications. 


THUNDERSTORM  ENVIRONMENTAL  MODEL 

The  thunderstorm  environmental  model  simu¬ 
lates  the  low-altitude  flight  environment  of  a 
moderate  to  severe  thunderstorm  for  an  aircraft 
on  approach,  landing,  and  takeoff.  This  termi¬ 
nal  area  simulation  model  contains  a  strong, 
small-scale  downdraft  which  penetrates  to  the 
ground,  forming  a  time-variant  gust  front  which 
travels  and  grows  along  the  ground.  The  entire 
simulation  model  provides  outputs  which  vary 
according  to  the  aircraft's  position  in  three- 
dimensional  space  and  time.  The  model  is  based 
upon  triple  Doppler  radar  observations  of  a 
typically  moderate  Spring  thunderstorm  which 
occurred  during  1978  outside  Chicago,  Illinois. 

This  particular  thunderstorm  had  a  33,000- 
foot  radar  top  and  showed  reflectivities  of  up 
to  60  dbz,  indicating  heavy  precipitation  rates 
were  present.  This  thunderstorm  contained  up¬ 
drafts  on  the  order  of  40  ft/s  and  downdrafts  of 
about  26  ft/s.  A  prestorm  meteorological  sound¬ 
ing  provided  the  temperature,  humidity,  and  wind 


structure  surrounding  the  storm.  Data  tapes 
from  triple  Doppler  radar  analyses,  containing 
mean  horizontal  wind  velocities  at  about  2, 600- 
foot  resolution,  were  used  as  the  basis  of  data 
generation. 


Most  radar  analyses  have  difficulty  with  low- 
altitude,  small-scale  phenomena  which  are  criti¬ 
cally  important  to  a  terminal  area  flight  simula¬ 
tion.  Ground  clutter  destroys  much  of  the  value 
of  the  low-altitudes  returns  which  are  close  to 
the  radar.  The  large  horizontal  resolution  of 
most  radars  masks  many  fine  details  in  the  wind 
structure  being  analyzed.  In  this  thunderstorm 
downdrafts  may  have  existed  at  a  few  locations 
but  none  were  resolved  well  enough  for  simula¬ 
tion  purposes.  One  of  the  most  probable  loca¬ 
tions  was  selected  and  a  mathematical  downdraft 
model  was  used  to  provide  the  fine  resolution 
required  for  simulation  of  the  downdraft  and  its 
resultant  gust  front  over  a  30-minute  time  span. 

This  second-order  closure  turbulence  model 
provides  data  which  corresponds  well  with  pub¬ 
lished  real-world  thunderstorm  data.  The  down- 
draft  model  provides  vertical  and  horizontal 
wind  components,  temperature  and  pressure  devi¬ 
ations,  three  turbulence  rms  values,  and  a  scale 
length  at  each  point  in  the  downdraft  grid.  The 
axisymmetric  downdraft  model  extends  to  about 
30,000  feet  and  resides  within  the  larger  (20  nm 
x  20  nm  x  3,200-foot)  storm  data  box. 

Data  within  the  storm  box  was  derived  from 
the  triple  Doppler  radar  horizontal  wind  compo¬ 
nents  and  the  prestorm  sounding.  Vertical  velo¬ 
cities  were  derived  by  integration  of  the 
inelastic  continuity  equation.  These  vertical 
velocities  and  the  prestorm  sounding  were  used 
to  create  the  overall  temperature  and  pressure 
deviation  fields  within  the  storm  box.  Turbu¬ 
lence  was  assumed  isotropic  outside  the  downdraft 
region  and  turbulence  rms  values  were  calculated 
by  stress  analysis  of  the  wind  components  within 
the  storm  box. 

If  the  aircraft  is  within  the  downdraft 
region,  both  data  sets  are  combined  to  provide 
the  final  environmental  data.  To  avoid  counting 
velocities  twice,  the  storm  box  values  within 
the  downdraft  region  have  been  adjusted  so  that 
mass  continuity  is  maintained.  Precipitation 
rate  and  visibility  were  derived  from  radar  re¬ 
flectivity  data  using  a  convective  precipitation 
rate  formula.  Final  outputs  of  the  thunderstorm 
environmental  model  include  three  components  of 
wind,  three  turbulence  component  rms  values,  tur¬ 
bulent  scale  lengths,  temperature,  pressure,  pre¬ 
cipitation  rate,  and  meteorological  visibility. 

The  ddwndraft  and  storm  box  data  sets  are 
compressed  for  disk  storage  and  are  accessed 
only  as  required  by  aircraft  movement  through 
the  downdraft  and  storm  box.  The  downdraft  data 
set  is  composed  of  ten  data  files  at  3-minute 
intervals  and  each  file  contains  eight  variables 
at  each  of  the  1,024  data  points.  The  storm  box 
data  set  consists  of  eleven  3-minute  time  files, 
each  with  4,418  data  points  containing  9  vari¬ 
ables.  The  thunderstorm  environmental  model  is 
programmed  in  FORTRAN. 

The  instructor  controls  the  location  and 
orientation  of  the  entire  storm  box  and  may 
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start  the  simulation  during  any  portion  of  the 
30-minute  time  period.  The  instructor  selects 
the  storm  translational  speed  and  direction  and 
a  downdraft  intensity,  which  are  limited  to  real 
world  values.  By  selecting  different  downdraft 
intensities  and  translational  speeds,  the 
instructor  may  simulate  a  mild  thunderstorm  or 
one  in  which  it  would  be  impossible  to  fly.  By 
positioning  the  storm  box  with  respect  to  the 
runway  in  time  and  space,  numerous  different 
thunderstorm  situations  may  be  simulated. 

Because  the  model  provides  outputs  which  vary  in 
both  time  and  space,  a  pilot  executing  a  go- 
around  maneuver  would  find  the  storm  had 
dynamically  changed  in  strength  as  well  as 
location.  In  fact,  a  pilot  could  wait  before 
takeoff  as  the  thunderstorm  passed  over,  and 
feel  the  turbulence,  winds,  and  precipitation 
effects  change  while  remaining  on  the  ground. 

The  thunderstorm  environmental  model  represents 
a  major  breakthrough  in  the  simulation  of  the 
storm  environment  and  four-dimensional  windshear 
effects  for  flight  simulation. 

TOTAL  SIMULATION 

To  complete  the  realistic  simulation  of  a 
thunderstorm,  other  visual  and  aural  cues  are 
provided.  Color  weather  radar  echoes  are  dis¬ 
played  which  dynamically  change  in  size  and  are 
coordinated  in  time  and  space  with  the  meteor¬ 
ological  outputs.  The  radar  echoes  appear 
initially  at  the  correct  altitudes  and  grow  and 
decay  vertically  and  horizontally  with  time. 

The  individual  cell  echoes  may  translate  and 
rotate  in  real  time.  The  color  weather  radar 
simulation  includes  beam  spreading,  and  range 
and  precipitation  attenuation  effects. 

The  precipitation  rate  output  from  the  thun¬ 
derstorm  model  is  used  to  simulate  the  sound  of 
rain  or  hail  in  the  cockpit.  Wind  and  turbulence 


components  can  be  used  to  provide  sound  direc¬ 
tionality.  The  sight  and  sound  of  thunder  and 
lightning  under  the  instructor's  control  are 
being  developed.  Visibility  effects  are  simula¬ 
ted  as  the  aircraft  enters  precipitation.  A 
visual  thunderstorm  display  is  being  developed 
to  provide  a  distant  view  that  might  be  observed 
on  approach. 


CONCLUSION 

In  order  to  provide  correct  training,  it  is 
important  to  use  real-world  data  in  simulation. 
The  complexities  of  thunderstorms  require  a  large 
dynamic  data  base  which  can  coordinate  the  many 
required  effects  and  free  the  instructor  to 
supervise  the  training  session.  Recent  Doppler 
radar  analyses  of  thunderstorms  can  now  provide 
data  bases  suitable  for  simulation,  making  simu¬ 
lator  training  for  realistic  hazardous  weather 
flight  procedures  now  possible.  It  is  most  im¬ 
portant  that  a  dynamic  physical  model  of  a  thun¬ 
derstorm  provide  outputs  to  other  visual  and 
aural  systems  in  order  to  create  a  comprehensive 
and  coordinated  simulation. 
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ABSTRACT 

Current  Air  Force  practices  invoke  the  Proqram  Planninq  Review  (PPR)  and  its  associated 
data  submissions  and  review  meetinqs  on  all  new  simulator  procurements.  The  PPR,  as  de¬ 
fined  by  Air  Force  policy,  provides  both  the  contractor  and  Air  Force  proqram  offices  with 
insiqht  into  the  proqram  plans  to  insure  successful  completion  of  all  contract  objectives. 

The  PPR  requirements  have  been  the  subject  of  recent  comments,  studies,  and  reviews.  The 
resultinq  opinions  have  consistently  questioned  the  "need"  for  the  in-depth  planninq  and 
related  data  submissions  required  to  support  the  PPR  Milestone  within  the  first  four  months 
after  contract  award.  The  arquments  both  for  and  aqainst  concern  the  quantity  of  data 
submitted,  the  number  of  reviews  scheduled,  and  the  resultina  impact  on  the  contractor. 

This  paper  summarizes  the  successful  completion  of  the  PPR  requirements  on  a  current  Air 
Force  simulator  contract  where  proper  preparation  and  implementation  of  the  proqram  plans 
by  the  contractor,  and  prompt,  explicit  review  by  the  qovernment,  resulted  in  a  proqram 
baseline  which  has  met  all  cost  and  schedule  objectives  to  date. 


INTRODUCTION 

The  Proqram  Planninq  Review  (PPR)  --  is  it  a  new 
milestone  or  another  millstone?  Technical  Reviews 
conducted  in  accordance  with  MI L-STO-1521  to  assess 
the  deqree  of  completion  of  major  technical  mile¬ 
stones,  have  been  a  normal  part  of  Air  Force  pro¬ 
curement  practices  for  many  years.  We  are  all 
familiar  with  the  System  Requirements  Review  (SRR), 
the  Enqineerinq  Desiqn  Review  (EDR),  the  Pre¬ 
liminary  Desiqn  Review  (PDR),  and  the  Critical  De¬ 
siqn  Review  (CDR).  Althouqh  many  view  these 
technical  milestones  as  the  most  important  events 
in  a  desiqn  and  development  project,  their  success 
can  only  be  as  qood  as  the  underlyinq  planninq 
leading  up  to  their  execution.  The  Air  Force  has 
formally  recoqnized  this  planninq  need  within  the 
past  couple  of  years  via  the  implementation  of  the 
Proqram  Planninq  Review  milestone. 

The  Air  Force  defines  the  Proqram  Planninq  Review 
as  a  milestone  which  provides  executive  level 
management,  in  both  the  Air  Force  and  contractor 
organizations,  with  insiqht  into  the  prnqram  plan¬ 
ninq  and  overall  manaqement  approach  to  be  utilized 
in  executinq  the  requirements  of  a  particular  con¬ 
tract.  Execution  of  this  milestone  has  now  become 
a  standard  part  of  all  Air  Force  simulator  pro¬ 
curements.  Normally  the  Air  Force  requires  that 
the  PPR  he  conducted  early  in  the  proqram,  i.e., 
within  the  first  110  days  of  contract  award. 
Successful  completion  of  the  milestone  is  normally 
defined  as  submission,  review,  and  approval  of 
several  contract  data  items;  the  execution  of  a 
formal  meetinq  at  which  the  contractor  oresents  his 
Proqram  Manaqement  Plan;  and  the  completion  of  an 


executive  level  session  attended  by  contractor  and 
qovernment  manaqement  to  critique  the  activities 
leadinq  up  to  the  PPR  Milestone. 

PPR  DATA  REQUIREMENTS 

Air  Force  operatinq  instructions  normally  specify 
that  certain  specific  planninq  documents  be  de¬ 
livered,  reviewed  by  the  qovernment  and  deemed 
satisfactory,  before  the  Proqram  Planninq  Review 
milestone  can  be  considered  complete.  The  F - 1 6 
Digital  Radar  Land  Mass  Simulator  (DRLMS)  Con¬ 
tract,  executed  in  1981,  included  a  collection  of 
most  of  the  plans  required  for  the  standard  PPR 
milestone  as  follows: 

1.  Configuration  Manaaement  Plan  (DI-E-3108) 

2.  Proqram  Mi  1 estones  (DI-A-3009/M? ) 

3.  Integration  Support  Plan  (DI-L-30318) 

4.  System  Test  Plan  ( D I -T- 3/01A/M1  ) 

5.  Technical  Manual  Plan  (OI-M-6154) 

6.  Computer  Proqram  Development  Plan 
(D I -F -3056  7A/M4  ) 

/.  Contract  Work  Breakdown  Structure 
(OI-A- 3023/MI 

8.  Firmware  Development  Plan 
(UOI-F. -393B-ASD/M3 ! 
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y.  Systems  Fnqineerinq  Plan  (I'l-S-Thl'-:  Ml 

10.  Production  Plan  (DI-P-3460/M ! 

In  addition,  the  Air  Force  mav  also  require  i.-- 
livery,  review  and  approval  of  additional  data 
items  involvinq  plannina,  orior  to  closing  the  PPP 
milestone.  These  may  include  the  Syste-'  Safety 
Proqram  Plan,  Reliability  and  Maintainability  De¬ 
monstration  Plan,  the  Pre-operat 1 ona 1  Support  Plan, 
and  Traininq  Planninq  Information. 


PLANNING  EXPERIENCE 

The  F - 1 6  DRLMS  PPR  Milestone  was  defined  to  be  com¬ 
plete  by  the  fifth  month.  Althounh  this  was  beyond 
the  110  day  recommendation  of  Air  Force  operatinq 
policy,  it  proved  to  be  a  more  suitable  schedule 
for  a  development  proqram  scheduled  to  run  for 
forty  months.  The  contract  also  required  the  de¬ 
velopment  and  delivery  of  several  other  plannina 
documents,  in  addition  to  the  ten  (10)  identified 
above.  Althouqh  these  were  not  prerequisite  to 
satisfactory  completion  of  the  PPR  Milestone,  they 
were  scheduled  to  be  submitted  within  the  first 
five  months  of  the  contract,  thus,  addinq  to  the 
contractor's  plannina  workload.  Of  the  fourteen 
plans  specified  for  submission  within  the  first 
five  months,  ten  of  the  plans  were  due  within  the 
first  90  days  with  seven  of  these  scheduled  to  be 
submitted  within  the  first  60  days! 

Why  does  the  Air  Force  insist  upon  this  ex¬ 
traordinary  amount  of  planninq?  The  record  shows 
that  the  reason  for  most  proqram  fai lures  over  the 
past  several  years  is  due  not  to  weak  execution, 
but  to  poor  planninq  --  unrealistic,  inadequate, 
and  insufficient  plannina  is  the  most  likely  cause 
of  proqram  failure.  Planninq  is  usually  cited  as 
beinq  the  first  of  the  five  fundamental  functions 
of  manaqement;  the  others  beinq  orqanizinq,  staff¬ 
ing,  directinq,  and  controlling.  Planninq  is  of 
particular  importance  in  research  and  development 
project  manaaement  because  usually  there  is  no 
other  experience  factor  to  rely  on  for  comparing 
actuals  versus  experience,  as  there  is  in 
manuf acturinq. 


PLAN  THE  PLANS 

Why  are  so  many  plans  required  which  seeminaly 
overlap  and  duplicate  each  other?  A  good 
performance  measurement  plan  provides  a  thorough 
definition  of  all  aspects  of  the  contractual 
effort.  Schedulina  is  an  important  and  integral 
part  of  the  overall  planninq  effort  because  the 
scheduling  process  forces  people  to  quantify  their 
effort  in  discrete  terms  and  place  their  tasks  in 
proper  relationship  to  each  other.  This  task 
identification  is  naturally  facilitated  bv  usina  a 
proper  work  breakdown  structure  to  progressively 
identify  each  element  of  the  item  under  develop¬ 
ment,  as  well  as  the  activities  required  to 
accomplish  the  effort.  Since  a  "Plan  for  Planning” 
is  necessary  to  insure  integration  nf  all  plan- 
n i nq/schpdu 1 inq  functions  with  the  contractual 
schedule  constraints,  which  mav  bp  dictated  by  de¬ 
livery  dates,  program  milestones,  etc.,  it  is  only 
natural  that  the  Proqram  Milestone  and  Contract 
Work  Breakdown  Structure  data  items,  identified 
above,  are  usually  specified  for  delivery  early  in 
a  proqram. 
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maximum  extent  possible,  an  i  the  rescirce;  for 
accomplishing  the  work  are  proper  1  v  ider*  1 1  ’  e"  and 
allocated.  The  planninq  within  each  function)’ 
discipline  is  then  documented  per  the  requirements 
of  the  specific  data  item  descrip*  'on  as  note*  in 
the  previous  list  of  PP-  required  data  s-,t>m<  1 1  a  1  <  . 

Each  plan  forms  the  basis  f  r  effprti.e  rom-.ni-a- 

tion,  not  only  between  the  contractor  and  th.- 

qovernment,  but  more  i-porf.  ant  1  v,  between  the  re¬ 
sponsible  individuals  at  e-act’  leve>  witnir  poth 
organ i zat i ons .  Effective  r  om-un  i  r  at  1 0n  will  1  a  ; 
to  effective  management,  and  effective  communica¬ 
tion  must  be  a  dialogue  between  the  responsible 
individuals  within  and  between  each  organ i zat i on, 
and  not  merely  a  series  of  parallel  monoloaues. 
Effective  plans  are  most  efficiently  prepared  and 
reviewed  when  the  responsible  individuals  within 
the  affected  disciplines  perform  the  plannina  and 
revi ewing. 


TOO  MUCH  DATA? 

Now  that  we  understand  the  reason  for  the  plan- 
nina,  why  is  it  so  difficult  to  complete?  The 
fourteen  data  items  which  constituted  the  planning 
requirements  on  the  F-16  DRLMS  proqram  were  iust 
the  beqinninq.  During  the  first  five  months  of  this 
contract,  there  were  6b  data  submissions,  or 
approximately  one  submisine  every  second  working 
day.  Those  data  submittals  were  prepared  against  a 
total  of  29  different  data  item  descriptions, 
including  the  14  delineated  above.  These  submis¬ 
sions  ranaed  from  a  relatively  stra i ahtforward 
Aqenda  to,  and  includina,  a  comprehensive  Svstem 
Test  Planninq  document.  Air  Force  review,  comment., 
and  approval  were  required  on  39  of  the  ps  submis¬ 
sions.  Thp  "Plan  for  thp  Plannina"  worked!  Over 
/0%  of  the  bb  submissions  wpre  completed  on,  or 
ahead  of  schedule  by  the  contractor,  and  only  four 
of  the  deliveries  which  were  latP  werp  delinquent 
by  more  than  a  week . 


TOO  MANY  MEETINGS? 

The  Proqram  Planninq  Review  is  not:  the  only  meet- 
ina  scheduled  to  take  place  during  the  first  five- 
months  of  the  contract.  In  addition  to  planning 
and  preparing  data  for  submission  to  the  govern¬ 
ment,  the  contractor  must  also  perform  some  "real” 
work.  The  real  work  is  normally  the  output  of  the 
system  enqineerinq  process  conducted  during  the 
first  sevpral  months  of  the  program.  The 
spec  i  f  icat.  i  ons  must  be  reviewed,  the  functions 
analyzed,  the  requirements  allocated,  and  a  design 
synthesized  which  will  lead  to  a  preliminary  system 
description.  These  events  and  activities  must  also 
be  supported  bv  design  and  trade  studies,  and 
logistics  analyses.  The  results  are  then  reviewed 
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with  the  government  durinq  the  System  Require¬ 
ments  Review. 

Successful  completion  of  the  SRR  then  leads  to  the 
development  of  conceptual  desiqn  for  subsystem  com¬ 
ponents,  with  due  cons iderat ion  qiven  to  continu- 
inq  trade  studies  and  technical  interface  com¬ 
patibility.  Interface  agreements  are  established 
durinq  Interface  Control  Working  Group  (1CWG)  meet¬ 
ings  and  a  Part  I  Interface  Spec,  developed.  One 
or  more  Enqineerinq  Desiqn  Reviews  may  be  con¬ 
ducted  following  the  SRR  before  holding  the  first 
formal  Preliminary  Design  Review. 


MEETING  EXPERIENCE 

During  the  five  month  period  leading  up  to  the  pPR, 
the  F-16  DRLMS  Proqram  completed  a  Post  Award  Con¬ 
ference  (PAC),  a  System  Requirements  Review  (SRR), 
two  Enqineerinq  Dpsiqn  Reviews  (EDR),  two  Proqram 
Management  Reviews  (PMRs),  a  Provisioning  Guidance 
Conference,  a  Support  Equipment  Guidance  Con¬ 
ference,  a  Parts  Control  Board  Guidance  Con¬ 
ference,  two  ICWG  Meetinqs,  a  Tech  Pubs  Guidance 
Conference,  a  C/SCS  Imolementation  Review,  and 
finally  the  Proqram  Planning  Review  (PPR).  All  of 
these  meetinqs  were  completed  to  the  full  satisfac¬ 
tion  of  both  the  contractor  and  the  qovernment. 
Fortunately,  many  of  the  meetinqs  were  conducted 
"back-to-back"  to  minimize  the  impact  to  both 
orqanizations.  The  F-16  DRLMS  contract  also  re¬ 
quired  the  imolementation  of  coproduction  planninq 
to  meet  the  requirements  of  the  F-16  Multi-na¬ 
tional  Aqreement  as  qoverned  by  the  Memorandum  of 
Understanding  executed  in  June  19/5  by  the  United 
States,  Norway,  Denmark,  Selqium,  and  the 
Netherlands.  The  coproduction  involvement  added  a 
second  level  of  complexity  to  the  plannina  process 
and,  in  turn,  required  the  implementation  of 
Technical  Assistance  Agreements  and  data  export 
licenses  to  ensure  that  all  State  Department 
provisions  were  satisfied. 


PPR  MEETING 

As  noted  previously,  Air  Force  ooeratinq  policy  re¬ 
quires  that  a  formal  Proqram  Planninq  Review  Meet- 
inq  be  held  with  contractor  and  qovernment  repre¬ 
sentatives  to  -eview  the  proqram  management  plan. 
In  order  to  ensure  satisfactory  and  timely  review 
of  the  pertinent  detailed  plans  prior  to  their 
final  approval  and  implementation,  the  F-16  DRLMS 
Proqram  conducted  the  Proqram  Planninq  Review  in 
two  increments.  The  first  increment,  which  was 
conducted  in  the  middle  of  the  third  month  in  con¬ 
junction  with  a  PMR/EDR  meetinq,  included  a  review 
of  all  applicable  plans  submitted  durinq  the  first 
90  davs.  The  second  and  final  PPR  incremental 
meetinq  was  conducted  durinq  the  middle  of  the 
fifth  month  for  the  purpose  of  reviewing  the 
remaininq  planninq  documents  and  the  contractor's 
proqram  manaqement  plan.  The  typical  Air  Force 
Work  Statement  identifies  the  fnllowinq  topics  for 
discussion  durinq  the  presentation  of  the  program 
management  plan  at  the  Proqram  Planninq  Review: 

1.  Risk/problpm  identification,  ranking,  avoi¬ 
dance/reduction  and  control 

?.  Establishment  of  cost,  schedule  and  perfor¬ 
mance  baseline  (including  critical  path 
identification  and  manloading) 


d.  Progress  tracking  and  reporting  n*  the 
base  1 i nes 

4.  Definition  and  implementation  of  conting¬ 
ency  plans 

5.  Subcontract,  management 

6.  Government/contractor  relationships 

/.  Contractor  management  information  and  con¬ 
trol  systems 

Simolv  stated,  these  topics  provide  the  contrac¬ 
tor  with  the  opportunity  to  outline  his  management 
philosophy  and  techniques  for  "doing  business." 

PLANNING  CONTROLS 

Proqram  Manaqers  must  be  concerned  with  the  control 
of  expenditures  of  money,  time,  and  human  re¬ 
sources  to  achieve  the  desired  system  performance. 
Consequently,  Proqram  Manaqers  are  interested  in 
having  visibility  of  the  proqress  in  achievina  the 
desired  technical  performance,  cost,  and  schedule 
objectives.  In  this  effort,  they  are  in  turn,  de¬ 
pendent  upon  the  quality  of  data  furnished  by  the 
management  control  svstem.  The  foundation  of  the 
management  control  system  is  the  proaram  manage¬ 
ment  plan.  The  proqram  management  plan,  in  turn, 
is  the  collective  set  of  functional  plans  which 
start  with  the  Statement  of  Work  (SOW)  and: 

-  Determine  the  nature  and  scope  of  work 

-  Determine  the  resources  to  be  applied 

-  Determine  the  results  and/or  output  to  be 
achieved 

-  Establish  the  procedures  for  consistent- 
/systematic  handlinq  of  work 

-  Establish  the  policies  and  rules  for  rou¬ 
tine  repetitive  tasks 

-  Define  the  organizational  responsibi 1 ity- 
/accountabi 1 ity  for  accomplishments 

Define  the  sequence  of  actions  to  perform 
the  tasks 

Define  the  schedule  requirements 

Althouqh  plans  provide  the  Proqram  Manager  with  the 
manaqement  control  device  for  monitoring  proqress, 
the  principal  mechanism  fnr  achieving  an  integrated 
plan  is  the  work  breakdown  structure  (WRS).  Since 
an  important  aspect  of  proqram  control  is  the  pro¬ 
per  definition  of  the  task  to  be  performed,  the 
work  breakdown  structure  is  an  essential  device  for 
identifying  the  contractual  tasks.  For  program 
planning  and  performance  measurement  purposes,  it 
is  desirable  that  the  WRS  bp  structured  in 
accordance  with  the  way  the  work  is  actually  goina 
to  be  performed.  The  Air  Force  normally  specifies 
that  the  ton  three  IpvpIs  of  t.hP  contract  WPA  bp 
selected  from  options  contained  in  *ML-STn-881. 
the  summary  level  items  are  normally  included  in 
the  contract  and  should  providp  a  useful  structure 
fnr  future  contract  status  reporting.  The  contrac¬ 
tor  may  then  extend  the  WRS  in  anv  manner  he 
chooses  in  an  effort  to  divide  the  contractual 
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tasks  into  manaqeable  pieces  of  effort,  for  which 
internal  responsibility  can  be  assiqned.  Although 
such  a  breakdown  is  commonly  used  in  manufactur¬ 
ing,  it  is  usually  more  difficult  to  establish  in 
enqineerinq,  where  the  tendency  is  tn  describe  the 
effort  in  broad  qeneral  terms,  identifying  only 
near-term  effort  in  detail.  This  lack  of  task  de¬ 
finition  can  easily  lead  to  down-stream  surprises 
on  projects  which  appear  to  be  doing  well,  simply 
because  it  is  virtually  impossible  to  determine 
what  resources  are  required  for  unplanned  work. 
Thus,  we  see  once  aqain  the  necessity  for  early, 
adequate,  and  proper  planning  and  clanninq  con¬ 
trols. 


MANAGEMENT  TECHNIQUES 

How  can  the  proqram  management  team  develop  the 
dozens  of  data  submissions,  prepare  for  and  attend 
the  dozen  or  so  meetinqs,  and  still  be  able  to 
effectively  plan  manpower  requirements,  develop 
comprehensive  schedules  and  time  phase  budgets  dur- 
inq  the  same  period?  They  can't  --  and  they 
shouldn't  attempt  to!  Just  as  the  work  breakdown 
structure  is  a  formal  method  for  identifying  and 
defininq  the  contractual  tasks,  so  is  a  con¬ 
tractor’s  organizational  chart  a  representation  of 
the  formal  structure  which  reflects  the  manner  in 
which  the  contractor  will  orqanize  the  people  who 
will  do  the  work.  Effective  proaram  management 
plans  are  more  realistic  if  they  are  prepared 
"bottoms-up"  by  the  individuals  responsible  for 
their  ultimate  implementation.  The  F- 16  ORLMS  con¬ 
tractor  employed  matrix  management  techniques,  with 
full  delegation  of  responsibility  and  authority  to 
the  functional  organizations  and  individuals  re¬ 
sponsible  for  executing  the  tasks.  This  technique 
was  effectively  employed  during  the  period  leadinq 
up  to  the  Proqram  Planninq  Review  to  insure  that 
all  plans,  data  item  submissions,  and  formal  meet¬ 
inqs  were  properly  and  successfully  completed.  The 
proqram  management  staff  defined  the  "big  picture" 
viewpoint  to  insure  that  the  planning  details  being 
implemented  throughout  the  matrix  organization  were 
consistent  with  the  overall  contract  require¬ 
ments.  The  creation  of  a  mu Itidiscipl ined  proqram 
management  staff,  capable  of  "planninq  the  plan¬ 
ninq"  and  promulqatinq  the  policies,  procedures, 
and  philosophies  of  the  proqram,  insured  that  the 
functional  area  specialists  worked  toaether  for  the 
common  set  of  proaram  objectives. 


TEAM  WORK 

The  Proqram  Manaqers  must  establish  and  maintain  a 
relationship  of  trust  and  confidence  between  the 
government  and  contractor  proqram  management  func¬ 
tions.  These  relationships  should  be  built  at  all 
levels  of  interface  between  the  contractor  and 
government  to  insure  that  there  is  more  emphasis  on 
"what"  is  right,  rather  than  "who"  is  riqht. 
Neither  proqram  management  team  can  be  successful 
if  the  other  fails.  Therefore,  it  is  essential 
that  the  communications  channels  be  established  and 
kept  open  early  in  the  proqram.  Each  of  the  meet¬ 
inqs  specified  in  the  work  statement  provide  a 
vehicle  for  establishing  effective  communica¬ 
tions.  Each  of  the  planninq  documents  prepared  and 
submitted  by  the  contractor  for  government  review 
and  comment,  provides  a  vehicle  for  understanding 
by  both  orqani zat ions .  The  PPR  milestone,  and  thp 
events  leadinq  up  to  it,  will  be  successful  if  both 


organizations  are  equally  involved  in  achievina  the 
program  objectives.  The  contractor  must  understand 
the  government's  program  objectives,  and  the 
government  should  also  understand  the  contractor's 
objectives.  Planning  is  fundamental  to  the  pro¬ 
gram's  objectives.  How  can  you  tell  if  you  are  go¬ 
ing  to  achieve  thp  program's  objectives  if  you 
don't  have  a  plan  to  tell  whern  you  are  going? 


SUMMARY 

In  conclusion,  it  is  apparent  that  the  innumerable 
data  submissions  and  meetings  --  sauares  which  must 
he  filled  before  the  PPR  is  scored  complete  -- 
could  easily  be  viewed  as  a  "millstone"  bv  the  pro¬ 
gram  management  team.  The  F - 16  ORLMS  Program  has 
proved  that  the  "squares  can  he  filled"  with  posi¬ 
tive  program  impact.  Proper  planning  will  not  slow 
down  the  “real"  work.  It  will  insure  its  success. 
In  view  of  the  numerous  data  submissions  and  formal 
meetinq  requirements,  the  contractor  is  likely  to 
assign  work  priorities  which  will  satisfy  the  most 
people  in  the  near-term.  In  doing  so,  he  often 
gives  the  plannina  process  far  less  prioritv  than 
it  needs.  Much  to  his  surprise,  he  may  soon  find 
that  temporary  or  inadequate  submissions  have 
become  the  "baseline,"  thus,  a  new  problem  may 
arise  --  explaininq  why  the  measured  performance 
does  not  satisfy  the  criteria  set  forth  in  the 
"temporary"  (and  inadequate)  plan.  If  the  contrac¬ 
tor  finds  himself  in  this  vicious  circle,  he  may 
never  recover  enouqh  to  fully  develop  an  adequate 
plan.  Therefore,  the  Proqram  Planninq  Review  could 
indeed  become  a  "millstone"  to  the  proqram  manage¬ 
ment  team,  if  treated  lightly.  The  F - 16  DRLMS  Pro¬ 
aram  has  demonstrated  that  proper  proaram  plan¬ 
ning,  by  both  the  contractor  and  the  government, 
leads  not  only  to  successful  completion  of  the  PPR 
Milestone,  but  also  to  successful  implementation  of 
the  proqram  and  achievement  of  its  objectives. 
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SOME  MANAi.KMLN  T  INITIATIVES  CO  IMPROVE  EMBE I >1  >KI) 
COMMERCIAL  COMPUTER  AND  TRAINING  DEVICE 
LIFE  CYCLE  SUPPORT 


Wayne  W.  Gamble 
Veda  Incorporated 
131  N.  Ludlow  Street 
Dayton,  OH  45402 

ABSTRACT 

This  paper  discusses  some  of  the  problems  associated  with  the  use  of  commercial 
off-the-shelf  computer  systems  in  aircrew  training  devices  and  offers  some  suggestions 
for  improving:  the  life  cycle  management  of  commercial  computer  systems  in  such 
military  training  devices.  The  impacts  of  commercial  practices  and  computer  capacity 
limitations  are  addressed  as  well  as  acquisition  and  logistics  management 
considerations.  Improved  planning  and  management  effectiveness  will  be  needed  in  the 
1980s  to  ensure  that  computer  systems  are  supportable  and/or  replaced  during  the  life 
cycle  of  training  devices  systems.  Both  acquisition  and  logistics  support  agencies  will 
need  to  recognize  that  the  life  cycle  of  commercial  computer  systems  may  be  limited  by 
the  lack  of  computer  and  peripheral  vendor  support  and  by  the  lack  of  expansion 
capability.  Accordingly,  training  devices  will  need  to  be  designed  and  developed  to 
accommodate  computer  expansion  or  replacement.  Computer  system  expansion  or 
replacement  will  need  to  be  anticipated  to  minimize  training  device  to  weapon  system 
configuration  differences  caused  by  a  lack  of  computer  system  supportability  or 
capacity.  This  process  could  be  termed  "Pre-Planned  Product  Preservation  (P^)". 


INTRODUCTION 

Life  Cycle  support  of  commercial  off-the-shelf 
computers  embedded  in  training  devices  has 
traditionally  been  a  challenge  to  military  training 
device  managers.  Logistics  supportability  problems 
and  computer  capacity  limitations  have  plagued 
simulator  managers  since  digital  computers  were  first 
embedded  in  simulators.  Commercial  practices, 
acquisition  management  practices,  and  logistics 
management  practices  have  all  contributed  to  life 
cycle  support  problems. 

While  advancing  technology  and  improved 
management  practices  have  lessened  the  impact  in 
some  areas,  the  overall  life  cycle  supportability 
problem  remains. 

LOGISTICS  SUPPORTABILITY  PROBLEMS 

On  older  generation  computer  systems,  logistics 
supportability  could  be  prolonged  because  base  level 
maintenance  had  the  capability  for  piece/part  repair 
of  the  single-layer,  discrete-component  technology 
(core  memory  was  the  exception).  With  new 
technology  computer  systems  (multi-layer,  high 
density  boards),  base  repair  capability  has  become 
more  limited  with  increased  dependence  on  depot  level 
(contractor)  repair.  This  evolution  in  maintenance 
concept  has  occurred  with  commercial  users  (airlines) 
as  well  as  the  military.  With  increased  dependence 
upon  contract  depot  level  repair,  the  supportability 
problem  has  changed  from  that  of  providing  piece/part 
components  for  base  level  repair  to  that  of  finding 
contractors,  either  original  manufacturers  or  third 
parties,  for  depot  level  repair  and  spares. 

Because  of  rapidly  advancing  technology  and 
the  highly  competitive  environment,  commercial 
computer  companies  are  announcing  a  new  product 
series  of  computers  with  increasing  frequency  (every 
three  to  five  years).  As  new  products  become  mature 
and  accepted,  production  of  the  previous  series  is 
terminated.  Most  commercial  computer 

manufacturers  will  then  guarantee  support  of  their 


products  for  five  years  following  termination  of 
production  of  a  particular  computer  model.  Some 
companies  provide  support  for  a  longer  time  depending 
on  availability  of  spares  and  components,  availability 
of  company  skills,  and  the  total  computer  population 
supported.  There  are  indications  that  computer 
companies  who  are  predominant  suppliers  of  training 
device  computer  systems  are  recognizing  the  simulator 
user's  need  for  longer  support.  Most  companies, 
however,  particularly  those  who  do  not  have  a  large 
share  of  the  simulation  market,  appear  to  be  staying 
with  the  five-year  support  policy. 

The  availability  and  cost  of  depot  level  repair 
and  spares  from  original  manufacturers  and/or  third 
party  repair  contractors  are  highly  dependent  upon  the 
overall  demand  for  such  services.  Factors  affecting 
demand  include: 

Effect  of  Production  Status 

Support  is  available  while  the  product  is  in 
production  and  normally  for  at  least  five  years 
following  production  termination.  The  availability  of 
spares  and  repair  from  original  manufacturers  varies 
with  company  policies.  Some  will  bid  on  spares  and 
repairs  so  long  as  their  products  are  in  service,  though 
the  cost  is  likely  to  increase.  Others  simply  refuse  to 
bid  repairs  after  they  have  discontinued  guaranteed 
support  of  a  product.  Also,  computer  manufacturers 
may  or  may  not  maintain  an  in-house  repair  capability 
for  their  vendor-supplied  peripherals.  Thus,  repair  for 
peripherals  may  be  subject  to  another  level  of 
availability.  It  has  been  suggested  that  long  term 
computer  support  commitments  be  made  a 
requirement  in  all  simulator  acquisitions.  While  this 
would  be  highly  desirable,  there  is  some  question 
whether  it  could  be  enforced  since  such  a  commitment 
is  dependent  upon  the  integrity  and  continuity  of  the 
prime,  the  computer  vendor,  and  second  tier  peripheral 
vendors. 

Manufacturing  Rights  and  Data  Availability 

The  availability  of  repairs  from  third  party 
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repair  sources  is  frequently  dependent  upon  the 
availability  of  technical  data.  One  computer 
manufacturer  claims  that  the  documentation  furnished 
with  each  delivered  system  is  adequate  to  establish 
and  maintain  a  depot  level  repair  capability.  Others, 
however,  furnish  limited  documentation  with  their 
equipment  and  consider  depot  level  technical  data  as 
proprietary  information.  Most  computer 

manufacturers  contacted  during  this  study  indicated 
that  they  would  consider  selling  proprietary  data  or 
manufacturing  rights  on  their  older  systems  if  they 
could  not  offer  repair  services.  It  was  noted  during 
the  study  that  third  party  repair  is  becoming  more 
readily  available  for  older  technology  systems. 
However,  there  is  some  question  whether  it  will  be 
economical  for  third  party  repair  sources  to  develop 
the  expertise  and  more  sophisticated  resources 
necessary  to  repair  newer  technology  equipment. 

Total  Production  Quantity 

Larger  total  production  quantities  of  an  item 
increase  the  probability  that  enough  units  remain  in 
service  to  economically  justify  retention  of  a  repair 
capability  for  a  longer  period.  Commercial  users  tend 
to  depreciate  computer  systems  over  about  five  to 
seven  years  and  then  replace  them,  while  the  military 
embeds  computers  in  equipment  that  is  intended  to  be 
used  for  15-25  years.  Frequently,  then,  the  military 
becomes  the  sole  user  of  commercial  computer  repair 
services  as  commercial  applications  are  phased  out. 

Equipment  Reliability  and  Sparing 

Computers  are  inherently  reliable  and  are 
becoming  more  so  with  new  technologies.  Thus,  the 
basic  repair  and  spare  demand  for  computer  circuit 
boards  is  low  compared  to  electro-mechanical  devices 
such  as  peripherals.  This  inherent  reliability  of 
computer  circuit  boards  makes  the  choice  in  sparing 
philosophy  more  difficult.  Although  at  least  one  of 
each  kind  of  board  is  spared  in  most  commercial  and 
military  simulator  applications,  long  term  support 
choices  involves  either:  (a)  dependence  upon 
contractor  repair  and  spare  support;  (b)  provisioning  a 
life-time  supply  of  spare  boards;  or  (c)  a  combination 
of  these.  AU  three  choices  involve  some  risk.  As 
indicated  above,  dependence  upon  contractor  support 
is  subject  to  limited  commercial  life  support  policies. 
Life-of-type  sparing  involves  high  front-end  costs  and 
less-than-perfect  predictions  of  failure  rates  .  A 
combination  of  contractor  dependence  until 
termination  of  guaranteed  support,  then  procuring  life- 
of-type  spares  is  subject  to  planning,  programming  and 
budgeting  lead  time  which  exceeds  the  one  year 
termination-of-support  notice  provided  by  some 
computer  vendors. 

Base  Level  Self-Sufficiency 

The  capability  of  base  (organizational  and 
intermediate)  maintenance  personnel  to  repair 
computer  components  can  have  a  significant  impact  on 
the  demand  for  depot  repair.  With  older  technologies 
(single-layer  discrete  component  boards),  both  military 
and  commercial  maintenance  personnel  could  maintain 
computers  with  a  high  degree  of  self-sufficiency. 
However,  with  newer  technologies  (multi-layered,  high 
density  boards),  both  military  and  commercial  users 
lack  the  skills  and  support  equipment  for  a  repair 
capability. 

As  the  older  technology  hardware  is  phased  out. 


an  increased  demand  for  depot  repair  can  be 
expected.  In  this  respect,  computer  companies  are 
limiting  their  field  engineers  to  troubleshooting  and 
board  removal-and-replaeement,  with  board  repairs 
accomplished  at  centralized  depot  level  repair 
facilities. 

As  the  demand  for  computer  spares  and  repairs 
diminishes,  it  understandably  becomes  more  costly  for 
repair  contractors,  whether  original  manufacturers  or 
third  party,  to  retain  the  skills,  parts  and  test 
equipment  for  a  support  capability.  The  current  Air 
Force  policy  of  competing  most  computer  repairs 
tends  to  discourage  the  commercial  retention  of 
support  capability  because  a  sustained  business  base  is 
not  assured.  The  relative  cost  of  depot  repair  during  a 
computer's  life  cycle  is  depicted  in  Figure  L  A  similar 
depiction  could  be  made  to  illustrate  spares  costs. 

EXPANSION  CAPABILITY  LIMITATIONS 

The  lack  of  expansion  capability  (computational 
timing  and  memory  requirements)  to  incorporate 
trainer  changes  has,  in  the  past,  frequently  been  more 
of  a  driving  factor  in  computer  replacements  than 
logistics  supportability.  Trainer  changes,  generated  by 
weapon  system  changes  and  by  increased  training 
requirements,  place  additional  demands  on  the 
originally  delivered  computational  system.  Solutions 
to  this  eventual  computer  system  saturation  include: 
(1)  expanding  existing  systems;  (2)  adding  another 
computer  system;  or  (3)  replacing  the  existing 
system.  Pertinent  aspects  of  this  problem  are 
contained  in  the  following  discussion: 

The  Developers'  Challenge 

With  a  few  exceptions  (e.g.,  Singer  GP-4),  older 
generation  computer  systems  used  in  simulators  were 
not  specifically  designed  for  real-time  simulation.  In 
order  to  meet  simulation  requirements  as  well  as 
government  imposed  spare  timing  and  sizing 
requirements,  simulator  developers  were  faced  with 
the  challenge  of  extracting  the  maximum  capability 
from  the  then  state-of-the-art  machines.  Techniques 
used  to  accomplish  this  were  (a)  modification  or 
replacement  of  the  computer  vendor's  software  and/or 
hardware,  (b)  use  of  machine  or  assembly  language 
and/or  more  efficient  software  programming,  and  (c) 
designing  interfaces  for  multiple  CPUs.  Even  with 
these  efforts,  simulator  developers  sometimes  had  to 
add  CPUs  during  development  and  frequently  delivered 
less  than  the  contractually-specified  spare  time  and 
memory  capacity.  It  may  be  noted  that  changing 
requirements  imposed  by  acquisition  agencies 
sometimes  contributed  to  this  problem. 

Spare  Time  and  Size  Requirements 

Acquisition  agencies  generally  plan  and 
contractually  specify  spare  time  and  size  to 
accommodate  change  activity  during  simulator 
development  and  for  delivery  to  the  using  command. 
Frequently,  however,  spare  time  and  size  is  used  by 
change  activity  and  other  factors  by  the  time  the 
system  is  delivered. 

Hindrances  to  Computer  Expansions 

Attempts  to  expand  computer  capacity  have 
been  affected  by  the  following: 

a.  Older  generation  computer  systems  had 
limited  expansion  capability. 
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b.  Because  of  the  Air  Force's  practice  of 
"freezing"  configurations,  computer  systems  had  to  be 
updated  to  the  latest  configuration  in  order  to  add 
capability.  Sometimes  it  was  determined  to  be  less 
expensive  to  replace  than  to  update. 

c.  Because  the  computer  system  was  obsolete 
(out  of  production),  expansion  kits  were  not  available. 

d.  Because  simulator  developers  had  modified 
the  computer  vendor's  software  and/or  hardware, 
vendor  updates  might  not  be  compatible.  Also, 
compatibility  with  the  vendor's  next  generation  of 
computer  systems  was  diminished,  making  applications 
software  less  transportable  and  more  costly  in  the 
computer  replacement.  More  often  than  not, 
simulator-unique  designs  led  to  sole  source 
procurement  of  the  computer  replacement  with  the 
simulator  developer  because  of  his  unique  design. 

Technology  Impact 

Recent  and  current  technology  computer 
systems  are  being  designed  with  increased  capability 
for  real-time  simulation.  In  addition,  these  systems 
are  more  easily  expanded  by  adding  such  things  as  a 
cache  memory,  a  high  speed  floating  point  processor, 
additional  CPUs  ,  or  extra  memory. 

COMMERCIAL  PRACTICE  CONSIDERATIONS 

A  number  of  practices  employed  by  computer 
and  simulator  manufacturers  contribute  to  the  overall 
management  problem.  Some  of  the  underlying  causes 
of  these  problems  are  being  overcome  by  advancing 
technology  and  improved  management  procedures. 
Other  practices,  however,  particularly  those  employed 
by  commercial  computer  vendors,  are  not  likely  to 
change. 


Revision  Procedures 

Computer  manufacturers  issue  service  bulletins, 
Product  Improvement  Notices  (PINs),  Field  Change 
Notices,  Design  Change  Notices,  or  otherwise 
designated  revision  levels  to  a  particular  item  of 
equipment  and/or  software.  Each  manufacturer  has 
his  own  system  of  issuing  revision  levels;  these  differ 
(sometimes  significantly)  in  cost,  description  of 
change,  inclusion  of  kits,  method  of  implementation, 
etc.  Some  manufacturers  issue  a  revision  that  consists 
only  of  a  drawing  correction.  Some  affect  hardware 
only;  some  affect  software  only;  and  some  affect  both. 

Revisions  may  be  issued  for  the  purpose  of: 

a.  Improving  computer  system  capability. 

b.  Improving  reliability. 

c.  Reflecting  manufacturing  changes. 

d.  Correcting  design  defects  or  field  reported 
problems. 

e.  Reflecting  component  or  material  changes 
or  substitutions. 

In  turn,  these  revisions  may  or  may  not: 

a.  Affect  form,  fit  and  function. 

b.  Require  prior  incorporation  of  a  lower  level 
revision. 

c.  Be  upward  or  downward  compatible  with 
other  revisions. 

d.  Be  fully  de-bugged  for  a  particular 
application. 

Typical  numbers  of  revisions  versus  computer  life- 
cycle  are  illustrated  in  Figure  2,  from  which  it  can  be 
seen  that  commercial  computers  have  a  very  dynamic 
configuration  baseline. 
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Configuration  Control  in  Acquisition 

Simulator  developers  have  not  always  delivered 
computer  systems,  spares,  and  technical  data  for  a 
given  trainer  type/model  in  a  common  or  current 
configuration.  Computers  or  spares  delivered  at 
different  times  could  include  different  revision 
levels.  In  recent  acquisitions,  the  Air  Force  has 
required  that  computer  systems  for  a  given  trainer 
type/model  be  updated  to  the  configuration  of  the  last 
delivered  trainer. 

Software  and  Hardware  Modifications 

Both  simulator  developers  and  computer 
manufacturers  advised  Veda  that  until  just  recently 
simulator  developers  have  modified  or  replaced  the 
computer  vendors'  operating  systems  (O/S)  and/or 
hardware  in  order  to  improve  the  "real-time" 
computational  capability  of  the  vendors'  systems.  This 
fact  alone  has  had  significant  impacts  on  simulator 
management: 

a.  If  vendor  operating  systems  and/or  hardware 
are  modified  or  replaced,  computer  vendors  cannot 
guarantee  that  their  hardware  updates  (revisions)  will 
not  affect  the  simulator  operation. 

b.  Vendors'  operating  system  revisions,  upon 
which  some  hardware  revisions  are  dependent,  may  not 
be  compatible  with  a  modified  operating  system. 

c.  Even  though  computer  manufacturers 
attempt  to  design  for  compatibility  from  one  computer 
model  or  generation  to  the  next,  modification  or 
replacement  of  the  operating  system  and/or  hardware 
make  the  applications  software  less  transportable. 
Thus,  software  costs  during  computer  replacements 
are  significantly  increased. 


d.  It  is  also  possible  for  simulator  developers  to 
use  the  vendor's  operating  system  intact,  but 
supplement  the  O/S  by  using  portions  of  the  computer 
not  used  by  the  then  current  O/S,  such  a_s  reserved 
memory  words.  A  subsequent  computer  vendor 
revision  to  the  O/S  utilizing  that  portion  of  the 
computer  is  then  not  usable  in  the  simulator 
application. 

e.  In  the  past,  most  simulator  developers  made 
at  least  minor  hardware  changes  to  vendor-supplied 
equipment.  This  was  accomplished  in  one  of  two  wavs: 

(1)  The  simulator  developer  would 
physically  modify  the  vendor's  part,  making  it 
simulator-unique  and  no  longer  an  off-the-shelf  item. 
If  handled  properly,  a  simulator  manufacturer  part 
number  would  be  assigned  to  the  resulting  assembly 
and  a  source  control  drawing  produced  and  delivered. 

(2)  The  simulator  developer  would  provide 
a  modified  design  and/or  specification  to  the  computer 
vendor,  who  would  produce  and  deliver  the  assembly 
with  a  vendor  part  number.  Although  the  assembly 
was  vendor  supplied,  it  most  likely  became  a  vendor's 
"specialized  proc  ict"  (versus  a  "standard  product")  and 
thus  simulator-u'  ique. 


Peripheral  Equipment  Modification 

A  related  problem  exists  with  respect  to 
modification  of  peripheral  equipment.  Some  computer 
manufacturers  modify  peripheral  equipment  or  specify 
modifications  to  the  peripheral  vendor.  In  either  case, 
peripheral  equipment  procured  directly  from  the 
peripheral  vendor  may  not  always  perform 
satisfactorily  in  the  delivered  computer  systems. 
Some  simulator  developers  procure  peripherals  through 
the  computer  manufacturer  in  order  to  preclude  the 
above  and  to  hold  the  computer  vendor  responsible  for 
total  computer  system  performance. 

The  Outlook 

It  should  be  noted  that  the  problem  associated 
with  manufacturer-modified  hardware  and  software 
may  not  be  as  severe  in  future  systems.  This  is 
because  currently  available  computer  systems  have 
been  designed  for  real-time  operations  and  have 
considerably  more  capability  and  expansion  potential 
than  previous  generations.  Both  computer  vendors  and 
simulator  developers  have  stated  to  Veda  that  the 
newer  technology  computer  systems  can  be  used  in 
simulation  applications  without  modification  of 
hardware  or  software.  One  simulator  developer,  while 
believing  this  possible,  suggested  that  modification 
would  still  be  required  because  of  cost  competitiveness 
and  the  customer’s  desire  to  "push  technology". 

ACQUISrriON  MANAGEMENT  CONSIDERATIONS 

Some  of  the  acquisition  practices  contributing 
to  computer  system  management  problems  have  been 
corrected  in  recent  acquisitions.  However,  because  of 
acquisition  lead  times,  the  effectiveness  of  these 
improved  practices  is  yet  to  be  demonstrated. 
Particular  aspects  of  current  versus  past  practices  are 
identified  in  the  following  discussions. 

The  Computer  Selection  Process 

Traditionally,  computer  systems  in  training 
devices  have  been  selected  by  the  simulator  developer 
during  the  acquisition  process  based  upon  general 
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computational  system  requirements  specified  by  the 
acquisition  agency.  Generally,  a  commercial  off-the- 
shelf  computer  system  is  selected  either  by  the 
simulator  developer's  choice  or  because  a  commercial 
system  is  specified  by  the  government.  The 
government,  however,  does  not  normally  specify  a 
commercial  brand  or  model.  The  basic  rationale  for 
selection  and/or  specification  of  commercial  systems 
for  simulation  has  been  as  follows: 

a.  Real-time  performance  and  memory 
capacity  requirements  for  simulation  applications  have 
required  state-of-the-art  computer  systems  designs; 
generally,  only  commercially  available  computer 
systems  could  meet  these  requirements. 

b.  The  quantity  of  computers  required  in  any 
one  simulator  system  type/model  has  not  justified  the 
development  of  a  military  computer  system  that  could 
meet  computational  requirements. 

c.  The  simulation  market  is  highly  competitive; 
thus,  cost  is  a  prime  consideration  of  the  simulator 
developer.  If  left  to  the  developer,  then,  a  least-cost 
system  meeting  performance  requirements  will  be 
selected. 

d.  Rapidly  advancing  technology  in  a  highly 
competitive  commercial  computer  market  has  made 
available  low  cost-to-performance  ratio  commercial 
systems,  thus  eliminating  the  need  for  high 
government  development  costs. 

This  method  of  computer  system  selection  has, 
in  the  past,  tended  to  proliferate  the  types  and  models 
of  computer  systems  in  training  devices  and  thus 
aggravate  the  logistics  support  effort.  More  recently, 
however,  the  increased  use  of  simulators,  and  more 
significantly,  the  increased  use  of  digital  computers  in 
simulation  have  lead  to  recognition  of  simulation  as  a 
computer  industry  market.  Because  of  this  market 
recognition,  computer  manufacturers  who  specialize  in 
real-time  systems  are  designing  them  with  a 
consideration  for  simulation  requirements.  This 
evolution  has  led  to  the  present  situation  wherein  it  is 
likely  that  computer  systems  of  the  minicomputer  or 
super-minicomputer  category  from  one  of  four 
manufacturers  are  selected.  Specifically, 

manufacturers  whose  systems  are  being  selected  today 
as  mainframe  computers  for  both  commercial  and 
military  simulator  applications  are:  Digital  Equipment 
Corporation  (PDP  or  VAX  series);  Gould  SEL  (32/77  or 
32/87  series);  Harris  (800  series);  or  Perkin-Elmer 
(8/32  or  3200  series).  While  the  current  selection 
process  has  essentially  reduced  proliferation  of 
mainframe  computer  systems  to  four  manufacturers, 
there  are  other  factors  that  affect,  or  may  affect,  the 
commercial  computer  selection  process: 

a.  No  single  computer  model  within  a 
manufacturer's  product  line  is  suitable  for  all 
simulator  applications  whereas  a  single  computer  of 
the  same  model  could  have  excessive  performance  (and 
cost)  in  other  applications. 

b.  Technology  innovations,  seemingly  being 
introduced  with  increased  frequency,  may  make  the 
current  training  device  computation  system  concept 
obsolete.  While  most  simulator  developers  contacted 
believe  that  a  mainframe  computer  will  continue  to  be 
used  in  simulations,  they  suggested  that  there  would  be 
increased  use  of  microprocessors  in  a  distributed 
mode,  and  that  the  physical  size  of  the  mainframe  witl 


decrease.  The  management  of  microprocessors 

presents  yet  another  challenge  to  simulator  managers. 

c.  In  spite  of  inflation,  the  eost-to- 

performanee  ratio  has  continued  to  decrease  with  the 
introduction  of  new  technologies.  This  trend  can  be 
expected  to  continue  for  the  foreseeable  future. 
Accordingly,  computational  system  cost  (excluding 
applications-unique  software)  will  continue  to  become 
a  smaller  percentage  of  the  overall  simulator  system 
cost. 

The  Simulator  Development  Process 

During  simulator  acquisition,  simulator 
developers  select  computer  systems  during  the 
proposal  phase.  In  order  to  minimize  risks  to  both  the 
government  and  the  developers,  a  reasonably  mature 
computer  (one  to  two  years  into  production)  is 
selected.  Based  upon  statistics  from  the  Air  Force,  a 
simulator  development  requires,  on  the  average,  34 
months  from  contract  award  to  delivery  of  the  first 
ready-for-training  (RFT)  simulator.  Therefore,  as 
illustrated  in  Figure  3,  computer  systems  are  four  to 
five  years  into  production  ,  or  perhaps  already  out  of 
production,  when  simulators  are  deployed.  Thus, 
logistics  managers  can  expect  to  experience 
supportability  problems  within  five  years  of 
deployment  of  the  first  training  device. 

For  new  simulator  acquisitions,  the  Deputy  for 
Simulators  prepares  a  Type  Bl,  Prime  Item 
Development  (Part  I)  Specification  and  requires  a  Part 
tl  Product  Specification  from  the  simulator 
developer.  The  training  device  is  procured  as  a  single 
Configuration  Item.  The  computational  system  is 
specified  by  incorporating,  or  referencing,  portions  of 
MIL-D-83468,  Digital  Computational  Systems  for 
Real-Time  Training  Simulators.  No  specification  per 
se  is  required  for  the  computer  system,  nor  are 
interface  specifications  or  interface  control 
documents  required.  Thus,  there  is  no  clear  distinction 
between  the  off-the-shelf  computer  system  and  the 
applications  (simulator-unique)  hardware  and  software. 

As  indicated  in  previous  discussions,  simulator 
developers  in  the  past  were  not  required  to  deliver 
computers  and  spares  in  a  common  or  current 
configuration;  however,  this  has  been  imposed  in 
recent  acquisition  contracts.  Also,  acquisition 
agencies  have  not  maintained  visibility  and  control 
over  modifications  to  computer  vendor's  hardware  and 
software.  The  Air  Force  has  recognized  this  and  is 
currently  intensifying  efforts  to  control  and  minimize 
these  modifications.  Finally,  contractually  specified 
spare  time  and  size  is  frequently  used  up  by  change 
activity  during  development.  This  problem  should 
become  less  of  a  concern  with  the  expandability  of 
newer  technology  computer  systems. 

Acquisition  Management  Initiatives 

The  provisions  of  an  acquisition,  of  course, 
strongly  influence  the  supportability  of  a  training 
device.  Thus,  computer  life  cycle  planning  must  begin 
with  the  acquisition  process.  If  it  is  recognized  that 
computer  replacements  are  inevitable,  then  training 
devices  should  be  designed  to  facilitate  such  computer 
replacement.  It  is  suggested  that  preservation  of  the 
off-the-shelf  nature  of  computer  systems  is  essential. 
This  translates  into  the  following  requirements: 


COMPUTER  LIFE  CYCLE 

(8  YEARS  PRODUCTION  PLUS  8  YEARS  GUARANTEED  SUPPORT) 


COMPUTER 

SYSTEM 
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SIMULATOR 

CONTRACT 

AWARD 


SIMULATOR  LIFE  CYCLE 

(18  YEARS  FOLLOWING  DELIVERY  OF  LAST  DEVICE) 


COMPARISON  OF  TYPICAL  COMPUTER  AND  SIMULATOR  LIFE  CYCLES 

FIGURE  3 


a.  Commercial  off-the-shelf  hardware  and 
software  must  be  used  without  modification.  Any 
deviation  should  be  fully  documented  and  justified  to 
the  acquisition  agency.  It  is  also  assumed  that 
applications  software  is  programmed  in  a  higher  order 
language  such  as  FORTRAN  or  Ada. 

b.  The  hardware  and  software  interface 

between  the  commercial  off-the-shelf  computer 

system  and  the  simulator  must  be  defined  and 
maintained  through  interface  control  documents  or 
other  comparable  means. 

c.  A  configuration  description  is  needed  to 

define  the  commercial  configuration  baseline.  Such  a 
configuration  description  is  normally  delivered  by  the 
computer  vendor  with  each  system,  and  describes  the 
hardware,  software,  and  documentation  as  delivered. 
The  computer  vendor's  current  configuration  of 
hardware,  software,  and  documentation  should  be 

maintained  during  development  and  be  reflected  in  the 
configuration  description  delivered  with  the  simulator. 

d.  A  technique  that  can  be  used  to  encourage 
simulator  contractors  to  consider  life  cycle 
supportability  is  to  require  a  Post  Production  Support 
Plan  as  a  part  of  acquisition  contracts.  The  Post 
Production  Support  Plan  is  described  in  MIL-STD-1388- 
1A,  Logistics  Support  Analysis,  and  Data  Item 
Description  DI-P-7119.  This  plan  requires  the  prime 
contractor  to:  (1)  identify  items  that  will  present 
potential  problems  due  to  inadequate  sources  of  supply 
after  termination  of  production;  and  (2)  prepare 
alternatives  to  satisfy  support  problems  for  the 
system/equipment's  expected  useful  life. 

If  the  above  requirements  can  be  fulfilled,  a 
current,  fully  documented  and  unmodified  commercial 


off-the-shelf  computer  system  will  be  delivered  with 
the  simulator.  Maintaining  the  off-the-shelf  integrity 
of  commercial  systems  should  facilitate  computer 
replacements  since  computer  manufacturers  try  to 
design  their  next  generation  computer  systems  to  be 
compatible  with  their  previous  generation  systems. 
Thus,  the  cost  and  complexity  of  computer  system 
replacements  should  be  minimized.  Requiring  a  Post 
Production  Support  Plan  should  greatly  enhance  Air 
Force's  planning  for  life  cycle  supportability  of 
commercial  computer  systems  including  peripherals. 

LOGISTICS  MANAGEMENT  CONSIDERATIONS 

Although  there  are  many  ramifications  to  the 
logistics  management  of  computer  systems,  there  are 
two  overriding  considerations:  configuration 

management  of  computer  systems  and  recognizing  the 
limited  life  cycle  of  commercial  systems. 

Configuration  Management 

Effective  logistics  management  of  embedded 
computer  systems  following  deployment  of  simulators 
has  been  hindered  by  a  lack  of  positive  configuration 
management.  Failure  to  maintain  computer  systems 
at  the  manufacturers'  current  configuration  levels  has 
created  mixed  configurations  of  spares,  data,  and 
installed  hardware  and  software  within  specific 
simulator  types  and  also  among  different  types  of 
simulators.  As  a  design  goal,  computer  manufacturers 
try  to  make  next  generation  computer  systems 
compatible  with  their  previous  generation  systems. 
This  compatibility,  however,  is  based  upon  the  latest 
configuration  of  the  older  generation  system.  Thus, 
failure  to  update  computer  systems  makes  logistics 
support  and  replacement  of  computer  systems  more 
difficult  and  costly. 
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Computer  Replacements 

The  need  for  computer  system  replacements 
one  or  more  times  during  a  simulator  life  cycle  is  not 
yet  established  as  a  recognized  requirement.  In  the 
past,  computer  replacements  have  been  driven  more  by 
lack  of  capacity  (time  and/or  size)  to  accept  simulator 
modifications  rather  than  by  a  lack  of  supportability. 
The  cost  of  replacing  computers  has  been  substantial 
because  software  was  programmed  in  machine  or 
assembly  language,  computer  systems  had  not  been 
updated,  and  modifications  had  been  made  to  off-the- 
shelf  software  and/or  hardware.  In  some  simulator 
systems,  this  replacement  cost  has  contributed  to  a 
significant  simulator  modification  backlog,  and  thus, 
to  degraded  training  because  of  weapon  system-trainer 
configuration  differences. 

Logistics  Management  Initiatives 

Based  upon  the  above  considerations,  there  are 
logically  two  logistics  management  initiatives  to  be 
considered:  maintaining  positive  configuration 

management  of  computer  systems  and  periodically 
reviewing  supportability  of  computer  systems. 

a.  Maintaining  positive  configuration 
management  of  computer  systems  includes  preserving 
their  commercial  off-the-shelf  nature  and  maintaining 
the  systems  and  documentation  to  the  manufacturers' 
dynamic  configuration  baseline.  To  accomplish  this, 
more  flexible  procedures  will  have  to  be  developed  to 
accommodate  the  manufacturers'  dynamic 
configuration  baselines. 

b.  In  order  to  provide  adequate  funding  lead 
times,  computer  system  supportability  must  be 
periodically  reviewed.  Using  the  Post  Production 
Support  Plan,  if  acquired,  this  review  should  include: 

•  Parent  weapon  system  inventory  plans 

•  Weapon  system  modernization  plans 

•  Trainer  modernization  plans 

•  Computer  spare  time  and  size 

•  Expandability  of  the  computer  system 

•  Availability  of  expansion  kits 

•  Vendor  support  policy  and  plans 

•  Availability  and  cost  of  support  from 
vendor  or  third  party 

•  Reliability 

•  Maintainability 

•  Any  modifications  made  to  off-the-shelf 
hardware  and  software 

•  Applications  software  program  language 

•  Compatibility  with  currently  available 
replacement  systems 

Because  of  the  rapidly  changing  commercial  computer 
market,  it  is  suggested  that  a  supportability  review 
should  be  made  on  at  least  a  biennial  basis,  and 
probably  annually  for  older  systems  and  peripherals. 

This  increased  management  attention  to 
embedded  computer  systems  should  contribute  to 
improved  logistics  supportability  during  the  life  cycle 
of  the  computer  system  and  to  improved  training 
effectiveness  during  the  life  cycle  of  the  simulator. 

SUMMARY 

There  are  many  factors  contributing  to  the 
problems  of  commercial  off-the-shelf  computer 


system  life  cycle  support.  Some  of  the  problems  are 
being  overcome  by  technology  while  others  are  being 
corrected  by  management  initiatives.  However,  full 
recognition  of  the  limited  commercial  computer  life 
cycle  is  needed,  along  with  acceptance  of  computer 
replacement  requirements. 

The  cost  and  mission  impact  of  computer 
system  replacements  can  be  minimized  if:  (1) 
simulator  developers  can  deliver  off-the-shelf 
commercial  computer  systems  without  modification; 
(2)  computer  systems  are  maintained  to  the  vendor's 
current  configuration;  and  (3)  supportability  of 
computer  systems  is  periodically  reviewed  to 
anticipate  replacement  requirements.  This  entire 
process  could  be  termed  "Pre-Planned  Product 
Preservation  (P^)". 
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ABSTRACT 

Aircrew  training  devices  for  the  teaching  of  tactical  combat  maneuvering  currently 
range  from  simple  desk-top  trainers  to  large  weapon  system  trainers  with  limited  visual 
systems.  Still  missing  from  the  spectrum  is  the  capability  to  practice  full-mission 
multi-ship  scenarios.  At  present  such  training  can  only  be  provided  by  major  field 
exercises  such  as  Red  Flag,  at  great  expense.  A  network  of  hostile-environment  simulators 
could  greatly  increase  the  frequency  of  training,  provide  more  realistic  training,  and  keep 
pilots  at  a  higher  state  of  readiness  than  by  using  aircraft  alone.  The  Air  Force  Human 
Resources  Laboratory  is  exploring  technology  requirements  for  multiple  aircraft  simulation 
under  Project  2743,  the  Combat  Mission  Trainer  (CMT)  program.  The  goal  is  to  develop  a 
full-mission  combat  simulator  affordable  at  the  wing  level  and  capable  of  training  all 
air-to-air  and  air-to-ground  tasks. 


INTRODUCTION 

With  all  of  man's  sophisticated  gadgetry 
and  knowledge  of  up-to-date  training  methods, 
there  still  does  not  exist  a  completely 
adequate  training  environment  for  practicing 
multiple-aircraft  weapons  delivery.  Although 
major  field  exercises  such  as  Red  Flag  closely 
approximate  the  realistic  scenarios  needed  for 
the  training  of  essential  combat  tasks,  field 


exercises  are  expensive  and  infrequent  and  do 
not  expose  pilots  to  actual  air  and  ground 
fire.  The  best  training  environment  of  all  is 
combat  itself.  Historical  data  from  World  War 
II  has  shown  that  losses  decrease  dramatically 
following  the  first  four  to  five  missions  of  a 
confrontation  (see  Figure  1).  Ideally,  pilots 
should  be  trained  in  advance  to  this  "fourth 
mission1'  level  of  readiness  to  increase  their 
survivability.  This  should  be  the  goal  of 
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Figure  1.  Losses  drop  remarkably  following  the  first  few  missions. 
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day-to-day  tactical  training. 


frequently  than  during  the  few  actual  live 
firings  permitted  now. 


Flight  simulators  are  slowly  evolving  into 
the  ideal  vehicle  for  providing  the  desired 
level  of  training.  The  use  of  simulators  could 
dramatically  improve  the  combat  capability  of 
the  Tactical  Air  Forces  (TAF),  and  serve  as  a 
valuable  complement  to  large-scale  field 
exercises  (1).  A  Red  Flag  exercise,  which  can 
consist  of  100  aircraft  flying  over  4000 
sorties,  is  an  extensive  undertaking.  The 
logistics  involved  in  getting  pilots  and 
aircraft  to  Nellis  AFB  are  of  such  magnitude 
that  most  pilots  are  able  to  benefit  from  the 
experience  only  on  an  annual  basis.  It  is 
impossible  to  maintain  exacting  skills  at  a 
peak  level  when  they  are  practiced  so 
infrequently.  If  combat  simulators  were 
available  at  every  wing,  practice  would  be  much 
more  intensive. 

Simulation  can  offer  many  other 
advantages.  Although  TAC  training  programs 
currently  provide  flight  in  the  presence  of 
threat  radar  emitters,  pilots  never  see  actual 
SAM  launches,  AAA  tracers,  etc.  In  the 
simulator,  ground  threats  can  be  accurately 
modeled  to  provide  striking  realism  for  the 
practice  of  defensive  maneuvers.  Seeing  a 
hostile  missile  approaching  his  aircraft  will 
make  a  believer  out  of  any  pilot  trying  to 
master  the  art  of  terrain  masking. 
Safety-of-flight  rules  of  engagement  such  as 
those  for  minimum  altitude  and  minimum 
separation  can  be  varied  at  will  in  the 
simulator  to  see  what  the  results  would  be  in 
actual  wartime  conditions.  Weather  conditions 
can  be  selected  for  the  particular  area  of  the 
world  for  which  you  are  training,  instead  of 
seeing  only  the  clear  dry  Nevada  desert  air 
encountered  in  the  Red  Flag  exercises.  The 
experience  level  of  adversaries  can  be  varied 
to  provide  increasing  challenges  to  pilots  as 
they  master  new  skills.  Unorthodox  or  unusual 
tactics  can  be  examined  to  determine  their 
feasibility.  Complex  scenarios  can  be  played 
back  immediately  for  thorough  debriefing  and 
analysis.  Expensive  weapons  such  as  the 
Maverick  missile  can  be  utilized  far  more 


CURRENT  TRAINING  DEVICES 

The  present-day  spectrum  of  aircrew 
training  devices  includes,  at  one  end,  simple 
terminals  for  computer-aided  instruction  and 
desk-top  trainers  with  interactive  graphics  for 
training  specific  instruments,  displays  and 
systems.  The  more  advanced  Cockpit  Procedures 
Trainers  and  Instrument  Flight  Simulators  may 
or  may  not  include  visual  systems  and  are  used 
for  basic  aircraft  systems  famil iarization, 
instrument  training,  and  limited  visual 
maneuvering.  At  a  still  higher  level, 
Operational  Flight  Trainers  and  Weapons  System 
Trainers  are  now  available  for  such  front-line 
aircraft  as  the  F-16,  F-lll  and  A-10,  but  these 
also  possess  only  limited  visual  systems.  This 
spectrum  must  be  extended  to  include  the 
full -mission  multi -ship  environment.  Some 
specialized  simulators  have  been  developed 
which  provide  limited  interaction  with  another 
aircraft  (see  Table  1)  but  none  of  these 
devices  provide  a  high  degree  of 
sophistication.  The  most  seriously  deficient 
area  is  that  of  the  complex  air-to-ground 
multi-ship  mission,  in  which  flight  leads  must 
coordinate  with  their  wingmen  and  with  other 
flights  while  evading  multiple  air  and  ground 
threats.  Filling  this  void  is  the  main  thrust 
of  AFHRL's  Combat  Mission  Trainer  Program. 


COMBAT  MISSION  TRAINER 

The  objective  of  the  Combat  Mission  Trainer 
(CMT)  program  is  to  develop  a  full-mission 
simulator  affordable  enough  for  widespread 
distribution,  effective  for  training  all 
air-to-ground  and  air-to-air  tasks,  and 
interconnectable  for  practicing  large-scale 
exercises. 

In  its  ultimate  form,  the  CMT  concept  would 
link  together  a  large  number  of  simulators  to 
provide  the  capability  for  practicing  major 
campaigns  at  greatly  reduced  cost  and  without 


TABLE  1 

SOME  CURRENTLY  AVAILABLE  INTERACTIVE  SIMULATORS 
AIR  REFUELING 


Boeing  C-5/C-141  Aerial  Refueling  Simulator 
Singer  B-52/KC-135  Weapon  System  Trainer 

AIR-TO-AIR 


Simulator  for  Air-to-Air  Combat  (SAAC) 
Visual  Technology  Research  Simulator  (VTRS) 
Device  2E6 
McDonnell -Douglas 

British  Aerospace  Air  Combat  Simulator 
AIR-TO-GROUND 


Advanced  Simulator  for  Pilot  Training  (ASPT) 


Seattle,  WA 
Castle  AFB,  CA 


Luke  AFB,  A2 
NTEC,  Orlando,  FL 
Oceana  NAS,  VA 
St.  Louis,  MO 
Warton,  England 


Williams  AFB,  AZ 
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Figure  2.  Interconnected  simulators  can  provide  superior  multi-ship  training. 


loss  of  life  or  equipment.  Such  a  system  would 
enable  pilots  to  interact  with  all  other 
participants  in  the  combat  environment, 
including  forward  air  controllers  and 
command-and-control  aircraft,  as  well  as  Army 
helicopters,  tank  formations,  and  other  ground 
units  (see  Figure  2). 

TECHNOLOGY  REQUIREMENTS 

Significant  technology  advances  must  be 
made  in  a  number  of  areas  before  the  CMT 
concept  can  become  reality.  A  viable  program 
for  developing  an  affordable  multiple-aircraft 
combat  simulator  must  address  the  following 
design  areas: 

1.  Visual  Display 

2.  Image  Generation 

3.  Data  Base  Generation  and  Update 

4.  Cockpit  Displays  and  Controls 

5.  Basic  Computational  Capability 

6.  Instructor  Operator  Station 

7.  Multi-Cockpit  Communication/Control 

Visual  Display 

The  most  critical  initial  problem  is  the 
development  of  a  new  visual  display  which  will 
provide  the  improved  field  of  view,  resolution, 
brightness,  and  color  required  for  an 
all-purpose  combat  simulator.  Combat 
simulation  requires  a  full  360-degree  coverage 
of  the  visual  scene,  which  is  not  attainable  in 
current  simulators.  Dome  or  dodecahedron 


simulators  can  provide  up  to  300°  horizontal 
by  150°  vertical,  but  do  not  provide  the  six 
o'clock  view  so  critical  to  tactical  survival. 
Limited  field  of  view  systems  such  as  those 
proposed  for  TAC  Operational  Flight  Trainers 
will  not  provide  the  necessary  coverage  for 
training  all  combat  tasks. 

Resolution,  brightness  and  contrast  must  be 
adequate  to  support  the  training  of  tasks 
requiring  acquisition  of  other  aircraft  or 
ground  targets.  Color  could  provide  useful 
differentiation  of  scene  details  which  are  of 
the  same  contrast  level.  The  display  must  be 
reduced  in  size  from  that  provided  by  current 
dome  and  mosaic  CRTs  in  order  to  eliminate  the 
associated  costs  of  a  large,  expensive 
supporting  structure  and  facility. 

Helmet  mounted  displays  appear  to  provide  a 
promising  solution  for  achieving  the  improved 
capability,  small  size  and  lower  cost  required 
for  the  CMT  application.  Some  current 
approaches  being  monitored  for  their 
applicability  include  AFHRL's  Fiber  Optic 
Helmet  Mounted  Display,  Aerospace  Medical 
Research  Laboratory’s  Visually-Coupled  Airborne 
Systems  Simulator  (VCASS),  and  the 
McDonnel 1 -Dougl as  Helmet  Mounted  Visual 
System.  For  a  complete  description  of  the 
AFHRL  approach,  see  the  paper  entitled  FIBER 
OPTIC  HELMET  MOUNTED  DISPLAY:  A  COST  EFFECTIVE 
APPROACH  TO  FULL  VISUAL  FLIGHT  SIMULATION 
elsewhere  in  these  proceedings. 
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A  typical  simulator  using  microprocessor 
technology  and  a  helmet  mounted  display  might 
appear  as  shown  in  Figure  3. 

Image  Generation 

Image  generators  for  the  CMT  must  provide  a 
high-quality  out-the-window  visual  scene  and 
multiple  sensor  displays  such  as  forward 
looking  infrared  (FUR)  and  radar. 

The  image  generator  is  presently  the 
greatest  cost  driver  of  the  entire  system.  In 
the  near  future,  if  image  generator  channel 
requirements  can  be  reduced  to  three  or  four 
through  the  use  of  head  coupled  displays,  then 
cost  could  potentially  be  reduced  to  $3-5 
million  per  simulator.  Systems  currently  in 
design  and  development  by  major  manufacturers 
could  be  used  for  an  interim  CMT,  but  no  real 
progress  will  be  made  in  this  area  until 
advances  in  Very  High  Speed  Integrated  Circuits 
(VHSIC)  and  Very  Large  Scale  Integration  (VLSI) 
produce  dramatic  decreases  in  cost  similar  to 
those  already  achieved  in  the  computer  industry. 

Scene  detail  as  determined  by  edge  count, 
texturing,  and  quadratic  surfaces  must  provide 
the  minimum  essential  information  required  for 
target  acquisition  and  low  level  terrain  cues. 
AFHRL's  Project  2363,  the  Advanced  Visual 
Technology  System,  will  provide  essential 
answers  to  the  questions  regarding  these 
minimum  levels  following  its  delivery  in  1984. 

Sufficient  moving  models  must  be  provided 
in  the  scene  to  handle  all  participants  who  are 


within  visual  range  of  each  other.  A  moving 
model  capability  is  being  included  in  new 
simulators  such  as  the  General  Electric  C-130 
simulator  at  Little  Rock  AFB,  and  the  proposed 
AV-8B  simulator  for  the  Cherry  Point  Marine 
Corps  Air  Station  being  built  by 
Rediffusion/Evans  S  Sutherland  (2).  However, 
more  moving  models  than  currently  available  on 
these  new  systems  would  have  to  be  included  for 
a  realistic  combat  scenario. 

FLIR  image  generation  poses  challenges  and 
risks  similar  to  that  for  outside  visual 
scenery.  Given  appropriate  algorithms  for 
handling  the  unique  characteristics  of  infrared 
imagery  such  as  atmospheric  and  time-of-day 
effects,  FLIR  imagery  can  be  produced  by  the 
visual  image  generator.  Air-to-air  radar  is 
not  difficult  to  simulate  and  should  be 
relatively  inexpensive  to  duplicate. 
Air-to-ground  radar  simulation,  on  the  other 
hand,  is  sufficiently  different  from  visual 
image  generation  that  it  requires  its  own 
separate  generator,  usually  referred  to  as  a 
Digital  Radar  Landmass  Simulator  (DRLMS). 
Current  air-to-ground  DRLMS  do  not  readily  lend 
themselves  to  the  CMT  concept  because  of  their 
expense.  Much  development  work  is  needed  to 
provide  a  low-cost  air-to-ground  radar 
simulation,  especially  for  the  newer  types  such 
as  Synthetic  Aperture  Radar  (SAR). 

Data  Base  Generation  and  Update 

The  present  capability  to  generate  and 
update  a  data  base  is  an  order  of  magnitude 
away  from  CMT  requirements.  If  possible,  only 


Figure  3.  Compact  design  envisioned  for  a  combat  mission  trainer. 
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Satellite  relay  is  unacceptable  due  to  the  long  transmission  time. 


one  data  base  should  be  required  for  storage  of 
all  out-the-window  and  sensor  parameters 
required  for  visual  representation,  infrared 
emissivity,  and  radar  reflectivity.  Extensive 
hand  modeling  must  give  way  to  automatic 
techniques  to  greatly  increase  the 
responsiveness  and  flexibility  of  the  system. 
Data  bases  must  be  capable  of  rapid  update  with 
the  latest  digital  terrain  data  from  the 
Defense  Mapping  Agency,  and  the  latest  threat 
information  from  various  intelligence  sources. 
Automatic  input  of  intelligence  data  is  a 
critical  requirement  for  responding  to  rapidly 
changing  threats.  For  best  efficiency,  rapid 
update  should  be  limited  to  just  threat, 
target,  and  minor  terrain  feature  relocation. 

Cockpit  Displays  and  Controls 

Development  of  cockpit  displays  and 
controls  is  a  low  risk  area,  since  this 
technology  has  been  demonstrated  repeatedly. 
Fabrication  of  cockpit  controls  is  a  minimum 
cost  item  compared  to  the  rest  of  the  system, 
although  some  specialized  displays  such  as 
radar  warning  receivers  and  Maverick  missile 
displays  may  be  required.  Fixed-stick  cockpits 
such  as  the  F-16  have  the  advantage  of 
requiring  no  control  loading  development. 

Newer  generation  aircraft  are  also  employing 
multipurpose  displays  which  will  help  eliminate 
the  need  for  large  numbers  of  specialized 
displays. 

AFHRL-developed  micro-linkage  techniques 
can  provide  an  inexpensive  connection  between 


cockpit  and  computers.  This  was  demonstrated 
on  the  U-2  Cockpit  Procedures  Trainer  (CPT) 
constructed  by  AFHRL  and  delivered  to  Beale  AFB 
in  1982  (3).  Use  of  micro-linkage  greatly 
increases  the  flexibility  of  the  system  and 
lowers  its  cost  by  reducing  the  required 
hardware.  Other  alternatives  to  the  linkage 
problem  have  been  proposed,  such  as  the  use  of 
separate  microcomputers  for  each  instrument  (4). 

Basic  Computational  Capability 

State  of  the  art  microprocessor  technology 
is  adequate  for  current  research  efforts.  A 
cost-effective  host  computer  using  commercial 
technology  is  practical  today,  although 
microprocessor  technology  is  moving  so  fast  it 
wouldn't  pay  to  rush  into  a  pre-production 
system  before  the  rest  of  the  CKT  is  ready. 
Distributed  microprocessor  technology  was 
effectively  utilized  in  the  AFH'.L  U-2  CPT  (3). 

Instructor  Operator  Station 

The  CMT  concept  will  require  an  extensive 
instructor  operator  station  (IOS)  to  monitor 
the  interaction  of  multiple  aircraft  during 
air-to-air  and  air-to-ground  maneuvers.  The 
ASPT  has  a  very  successful  air-to-ground 
display,  while  the  SAAC  can  display  three 
dimensional  air-to-air  maneuvering.  Neither  of 
these  designs  would  be  adequate  for  both 
air-to-air  and  air-to-ground  missions,  so  a  new 
concept  in  multi-mission,  multi-participant 
instructor  operator  stations  must  be  developed. 
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Mul tiple-Cockpi t  Communication/Control 

A  number  of  alternative  configurations 
exist  for  networking  from  two  to  fifty  combat 
simulators.  The  optimum  approach  is  to  make 
all  CMTs  stand-alone  capable,  and  connect  them 
to  a  central  control  facility  for  distribution 
of  position  data,  weapon  status,  and  damage 
determination.  Transport  delay  can  be 
minimized  by  passing  attitude  and  velocity  data 
and  predicting  the  correct  actual  position  for 
the  moving  models. 

Small-scale  experience  from  the  cross-town 
ASPT-SAAC  linkup  demonstrated  the  feasibility 
of  interconnecting  dissimilar  simulators 
through  telephone  lines  for  one-on-one 
air-to-air  combat.  AFHRL  will  test  simple  two 
to  four  cockpit  arrangements  in-house  to 
ascertain  the  feasibility  of  conducting 
multi-ship  multi-mission  training  with  more 
complex  air-to-ground  data  bases.  Once  the 
concept  is  proven  feasible  the  interconnection 
of  two  distant  simulators  can  be  tried  using 
microwave  links  and/or  land  lines.  The  use  of 
satellites  is  infeasible  (5)  because  the 
average  transmission  time  of  230  milliseconds 
gives  a  totally  unacceptable  transport  delay 
for  real-time  interactive  flight  simulators 
( see  Figure  4). 

Whatever  transmission  method  is  used, 
security  protection  becomes  a  vital  concern 
because  classified  tactics  would  be  vulnerable 
to  compromise  during  the  conduct  of  large-scale 
exercises.  Use  of  a  central  facility  for  rapid 
database  and  threat  updates  poses  a  high 
security  risk  during  the  transmission  of  new 
data  to  all  interconnected  simulators. 

A  full  CUT  system  would  also  require  a 
voice  communication  channel  for  participants  to 
communicate  with  each  other  and  with  their 
instructors.  This  will  further  complicate  the 
interconnection  process. 

CONCLUSIONS 

Combat  simulation  is  rapidly  becoming  a 
necessity  for  the  training  of  future  fighter 
pilots.  A  multi-cockpit,  mul ti-mission 
simulator  can  increase  readiness  by  improving 
the  weapons  delivery  capability  of  the 
participants  and  by  enhancing  their 
survivability. 


Advances  in  many  technical  areas  are 
required  before  widespread  combat  simulation 
will  become  a  reality,  but  continued  investment 
promises  ultimate  success  and  a  high  payoff. 
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considered,  and  some  actions  that  should  be  explored  if  resolutions  to  tm-  .  r 
are  to  be  achieved. 


INTRODUCTION 

When  the  Department  of  Defense  directed 
that  commercial ly  available  standard  off- 
the-shelf  computer  systems  would  be  used  for 
military  simulation  programs  in  place  of 
special  militarized  computers  the  intent  was 
clear:  Cut  costs!  Now,  more  than  a  decade 
after  the  DOD  directive,  it  is  possible  to 
look  back,  recognize  the  value  of  the  deci¬ 
sion,  and  identify  many  of  the  problem  areas 
that  have  been  created  for  the  military 
simulation  program  organizations. 

Though  the  commercial  computer  has 
provided  state-of-the-art  solutions  for  the 
increasing  demands  of  simulation  require¬ 
ments,  the  long  term  support  of  simulation 
systems  has  been  a  problem  that  has  eluded 
the  most  conscientious  efforts  of  the  mili¬ 
tary  services.  The  need  of  the  computer  in¬ 
dustry  to  stay  current  with  the  dynamic 
technological  advances  is  directly  opposed 
to  the  military  need  to  support  a  simulator 
for  a  useful  life  of  up  to  twenty  years. 

The  commercial  computer  has  a  production 
life  of  possibly  five  to  seven  years.  This 
production  cycle  is  steadily  decreasing. 

The  computer  system  support  software  has  a 
considerably  shorter  product  life. 

The  military  services  have  attempted 
to  address  the  problems  posed  by  the  ap¬ 
parent  conflict  of  needs  but  have  met  with 
minimal  success  to  date.  Mow  then  can  the 
benefits  ot  commercially  available  computers 
be  realized  without  the  excessive  costs  as¬ 
sociated  with  the  long  term  life  cycle  sun- 
port  of  those  systems? 

This  paper  is  a  computer  manut.n  t  .i-er'c 
look  at  some  of  the  support  prohle-s  that 
have  been  created  by  the  use  of  comr  ■<  iallv 
available  computer  systems,  some  of  'u. 
solutions  that  are  currently  being  u  1  and 
some  future  actions  wnir.h  should  tie  explored 
i(  resolutions  to  these  problems  are  to  be 
achieved.  1  he  paper  is  broken  down  into 
*  hi  * 1 1  •  sections  to  discuss  these  support  is¬ 


sues  and  their  resole* ’ nr  ir  .m  : 

Term  support.  Software  y  pa  f  i  T  i  i  i '  ,■ .  uni 
Obsolescence.  The  throe  .erf. ton 5  are  s  ti  r  1  - 
cal  Problems,  Current  'elutions,  and  Reco"  • 
nended  Solutions. 

T Hf  HISTTIRV  Of  Bi  t  f.OMMEWlAl  OiT-S';  I  ; 

COM!  1.,'T!  R  [TJiJlPf.'i 

In  the  early  1970s  it  was  mandated  tb.i' 
commercial  general  purpose  off-the-shelf  ■  c - 
puters  be  used  to  replace  the  specialized  si":, 
lat.on  computers  for  military  sun la  tors . 

The  directive  was  intended  to  reduce  ac¬ 
quisition  costs  and  to  reduce  support  costs. 
Historical ly.  in  a  training  device  environment 
these  computers  which  were  used  to  simulation 
on-board  computers  have  allowed  cost  effective 
performance  and  versatility  which  was  not 
available  with  specialized  computers  or  t ne¬ 
on -hoard  militarized  computers.  Ihe  on-board 
computers  were  targeted  for  operational  en¬ 
vironments  in  airborne,  aerospace,  s  <rface 
vehicles  and  submarine  appl  i  cat  ions  anj  cS-jr| 
had  an  adverse  impact  on  simulator  costs  both 
in  acquisition  and  support. 

It  was  further  envisioned  that  documenta¬ 
tion  costs  could  bo  reduced  by  using  standard 
off-the-shelf  commercial  ly  available  door  ci¬ 
tation,  i.e.,  operation  and  maintenance  manu¬ 
als.  This  is  a  significant  cost  savings  m 
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As  the  directive  to  buy  commercial  off- 
the  shelf  comuuters  began  to  be  executed 
several  problems  arose.  It  ust  be  said 
that  the  intention  of  the  buy  commercial 
idea  was  valid  and  appropriate.  The  imple¬ 
mentation  across  the  board  however,  was  not 
as  effective  as  it  could  have  been. 

HI STORIC At  i’ROBLLMS 

It.  has  been  field  proven  that  commer¬ 
cial  off-the-shelf  computers  can  be  used  in 
production  of  high  fidelity  training  de¬ 
vices.  Major  coiunerc  ial  computer  manufac¬ 
turers  generally  employ  people  who  can  un¬ 
derstand  military  training  device  computer 
requirements  and  can  communicate  effectively 
in  the  military  support  environment.  There 
are  several  major  problems  that  must  be  ad¬ 
dressed  to  field  and  maintain  simulators 
with  commercial  computers.  The  three  most 
significant  problem  areas  are: 

1.  Long  Term  Support 

2.  Software  Compatibility 

3.  Obsolescence 

This  paper  addresses  these  areas  from 
the  computer  manufacturer's  point  of  view. 
Several  beneficial  results  may  arise  if  the 
military  and  the  prime  contractors  under¬ 
stand  the  commercial  manufacturer's  view¬ 
point  on  these  problems  and  how  the  computer 
vendors  would  propose  to  solve  them. 

1 .  Long_  Term  Support. .  Typically  a 
commercial  system  is  obsolete  in  about  five 
years  in  the  commercial  marketplace  and  as 
technology  advances  this  life  cycle  is  be¬ 
coming  shorter.  A  military  simulator  is  not 
planned  to  be  obsolete  until  ten  to  twenty- 
five  years  after  initial  acceptance/deploy- 
ment.  The  wide  divergence  in  the  timframe 
is  part  of  the  problem.  Also,  the  command 
philosophy  of  long  term  support  is  different 
in  the  military  environment.  The  problem  is 
further  complicated  by  the  nature  of  change 
in  the  two  environments  and  by  the  methods 
used  to  address  change. 

If,  for  example,  we  take  a  commercial 
application  which  is  doing  engineering  work, 
it  would  be  expected  that  its  useful  life 
would  be  approximately  seven  years.  At  the 
end  of  this  period  the  system  will  be  re¬ 
placed  with  a  newer  model  with  more  capabi¬ 
lity.  At  the  initial  purchase  of  the  system 
no  documentation  other  than  commercial  manu¬ 
als  would  be  provided.  The  user  of  the  sys¬ 
tem  would  opt  for  maintaining  the  system 
himself  or  would  have  the  supplier  do  the 
maintenance.  If  he  chose  to  maintain  the 
system  himself  he  would  either  buy  the  ap¬ 
propriate  spares  to  support  the  system  at 
the  time  of  purchase  or  an  as-required 
ba  s  i  s . 

The  military  application  for  simulatot 
work  would  be  expected  to  have  a  useful  lite 
of  approximately  twenty  years.  At  the  end 


ot  this  period  the  system  would  be  updated  or 
retired.  Under  the  "buy  off-the-shelf"  philo¬ 
sophy  the  documentation  would  be  standard  com¬ 
mercial  manuals  or  possibly  modified  common  ial 
manuals.  The  customer  could  opt  to  maintain 
the  system  himself,  have  his  prime  contractor 
maintain  the  system  or  have  some  third  party 
maintain  the  system.  It  should  be  noted  that 
commercial  manuals  probably  won't  be  sufficient 
since  maintenance  personnel  are  rotated  through 
the  sites  at  intervals  which  don't  allow  them 
to  become  familiar  enough  with  the  equipment 
to  handle  major  failures. 

flow,  from  a  commercial  computer  manufac¬ 
turer's  point,  of  view  the  easier  system  to  sup¬ 
port  is  the  commercial  application.  First  of 
all,  the  maintenance  on  the  system  is  over  a 
shorter  period  and  he  can  keep  technicians  who 
are  trained  on  its  maintenance  and  who  feel 
that  they  are  not  working  on  antiquated  equip¬ 
ment.  Second,  he  can  supply  the  latest  revi¬ 
sion  level  of  parts  direct  from  the  factory 
since  he  is  maintaining  the  equipment.  Third, 
he  doesn't  have  to  worry  about  the  technical 
tra  ling  and  documentation  since  he  is  pro¬ 
viding  his  current  technical  manuals  and  pro¬ 
viding  maintenance  training  to  his  service 
people  on  his  current  equipment. 

The  peripherals  issue  is  also  one  of  the 
areas  which  is  effected  by  long  term  support 
requirements.  From  a  military  simulator  view¬ 
point  it  is  expected  that  the  system,  including 
peripherals,  will  have  a  useful  life  of  twenty 
years.  As  with  the  computer,  the  peripherals 
have  to  be  supported  with  spares  including 
mechanical  parts  which  tend  to  wear.  After 
approximately  five  to  seven  years  the  peripher¬ 
al  manufacturer  ceases  to  manufacture  the  pe¬ 
ripheral  and  discontinues  spares.  If  enough 
spares  are  not.  acquired  by  the  user  while  they 
are  available  then  the  equipment  will  become 
rapidly  non-functional  . 

Figure  1  indicates  the  levels  associated 
with  sparing  peripherals.  This  figure  indi¬ 
cates  a  simplistic  view  of  the  levels  that  must 
be  addressed  to  obtain  spares  for  long  term 
support.  When  multiple  manufacturers  and  mul¬ 
tiple  component  vendors  are  considered  the 
picture  becomes  extremely  complicated.  When 
multiple  revision  levels  from  multiple  manu¬ 
facturers  are  considered  it  becomes  even  more 
compl icated . 

The  military  simulator  as  viewed  from  a 
commercial  viewpoint  is  fraught  with  potential 
pitfalls.  The  computer  manufacturer  must 
change  the  way  he  does  business  in  spares, 
technical  resources  and  in  his  change  control 
systems.  The  commercial  manufacturer  must  also 
change  his  management  style  instituting  a  pro¬ 
gram  management  function,  and  keeping  product 
lines  alive  which  would  otherwise  be  termi¬ 
nated.  This  is  not  to  say  that  simulator  busi¬ 
ness  is  not  profitable  to  the  computer  manu¬ 
facturer,  if  properly  manageu.  but  is  compli¬ 
cates  matters  and  adds  to  the  cost  of  procure¬ 
ment  and  lite  cycle  maintenance. 
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2 .  Software  Compa t j b i 1 i ty .  So f twa re 
is  hard  and  hardware  is  soft.  This  state¬ 
ment  expresses  the  paradox  of  the  problem 
relating  to  commercially  available  software 
used  on  simulator  programs.  A.  computer 
manufacturer  constantly  produces  changes  to 
hardware  which  have  little  or  no  effect  on 
the  system  software.  However,  if  he  changes 
the  software,  then  watch  out!  These  changes 
ripple  through  a  simulator  system  causing 
repercussions  randomly  throughout  the  entire 
system. 

The  problem  can  be  exemplified  by  a 
simulator  system  which  is  hit  with  a  major 
operating  system  change  by  the  computer 
manufacturer  while  in  final  government  ac¬ 
ceptance  after  two  and  a  half  years  of  de¬ 
velopment  effort.  If  the  simulator  manu¬ 
facturer  doesn't  provide  the  latest  commer- 
cialny  available  software  both  the  prime 
contractor  and  the  computer  vendor  may  be 
technically  in  default  of  their  contracts. 

If  the  computer  vendor  implements  the  new 
operating  system  he  may  not  be  able  to  pass 
the  acceptance  tests  due  to  the  systems  im¬ 
pact,  and  he  could  then  be  in  default  for 
system  acceptance  testing.  It  is  a  “Damned 
if  you  do  and  damned  if  you  don't"  situa¬ 
tion. 

Even  frozen  configurations  of  software 
and/or  hardware  create  problems.  In  this 
scenario  the  software  and/or  hardware  con¬ 
figuration  is  frozen  to  specific  revision 
levels.  If  a  new  device  is  added  or  a  bug 
is  found  in  the  software  which  requires  a 
change  then  the  problems  rise  to  the  sur¬ 
face.  Since  the  revision  levels  were  fro¬ 
zen,  x  changes  have  probably  occurred  in  the 
commercial  releases  of  the  software.  There¬ 
fore,  the  simulator  program  is  faced  with 
either  creating  a  non-standard,  non-commer¬ 
cial  software  package  which  fixes  the  bug  or 
having  to  test  the  latest  release  of  the 
software  and  face  the  risk  of  incompatibi¬ 
lities  and  the  potential  new  bugs.  Yet 
another  problem  is  the  failure  of  software 
which  works  at  revision  X  to  work  at  Y. 

This  may  occur  if  programming  or  language 
standards  were  not  followed  by  the  program¬ 
mer.  This  can  occur  when  one  revision  of 
the  software  is  forgiving  in  allowing  the 
programmer  to  deviate  from  standards  and  the 
next  revision  demands  rigid  comformity  to 
standards. 

Disaster  lurks  in  the  multi-system 
environment  when  all  developers  are  not 
using  the  same  revision  of  the  computer 
manufacturer' s  software.  Software  control 
or  lack  thereof  is  perhaps  the  greatest 
problem  area.  The  clever  programmer  who 
gets  around  the  software  assures  that  future 
updates  to  the  system  software  are  not  com¬ 
patible  with  the  previous  release  which 
worked.  This  must  be  handled  by  imposing 
and  enforcing  development  standards  on  the 
prime  contractor. 


3.  Obsolescence.  The  environment  which 
is  typified  by  the  simulator  world  is  one  of 
constant  change.  By  this.  I  mean  everything 
is  changing  but  not  necessarily  at  any  fixed 
rate.  The  state-of-the-art  in  computer  hard¬ 
ware  is  changing.  The  software  techniques  are 
changing.  The  level  of  technical  expertise 
and  the  vehicle  being  simulated  is  changing. 

Hardware  trends  indicate  that  the  fol¬ 
lowing  things  will  occur  in  the  future,  first , 
memory  will  become  cheaper.  Second,  computa¬ 
tional  power  will  become  cheaper.  Third,  pack¬ 
aging  will  become  smaller,  from  a  simulator 
viewpoint  this  means  that  in  spite  of  long 
term  planning,  a  program  started  in  1975  will 
be  using  a  computer  which  is  expensive  to  ex¬ 
pand,  expensive  to  maintain  and  technically 
obsolete  in  1982. 

This  is  acceptable  from  a  military  user- 
point  of  view  as  long  as  spare  capacity/growth 
provisions  for  computer  time  and  memory  remain 
and  the  simulator  meets  its  operational  re¬ 
quirements.  Their  viewpoint  soon  degenerates 
to  unhappiness  when  the  simulator  changes  eat 
up  the  growth  capacity  and  the  device  can  no 
longer  meet  its  performance  or  supportabi 1 i ty 
requirements.  From  a  logistics  point  of  view 
it  can  approach  a  nightmare. 

How  can  that  happen,  you  may  ask?  Well, 
for  one  thing,  spares  are  in  the  national  sup¬ 
ply  system  at  assorted  revision  levels.  Unless 
spares  are  kept  with  a  simulator,  there  is  no 
guarantee  that  a  board  from  the  national  sup¬ 
ply  system  will  work  in  a  given  system  because 
of  the  revision  level  differences.  There  is, 
on  the  other  hand,  no  certainty  that  it  won't 
work  either. 

How  did  this  mess  come  about?  Simple,  we 
procured  and  engineered  ourselves  into  it.  For 
example.  Program  X  freezes  its  configuration  of 
hardware  at  level  B  (B  is  made  up  of  multiple 
boards  at  various  levels).  Program  Y  maintains 
its  systems  at  current  manufactured  revision 
levels.  Program  Z  opts  to  block  upgrade  its 
simulators  so  that  the  first  shall  be  like  the 
last  in  revision  level  and  is  currently  half¬ 
way  through  a  program  which  will  field  simula¬ 
tors  for  the  next  five  years.  Obviously  some 
programs  spares  are  obsolete  and  more  than 
likely  most  are.  There  is  no  logistics  program 
that  crosses  contract  lines  to  assure  that  all 
parts  of  the  same  number  from  the  same  commer¬ 
cial  manufacturer  are  interchangeable. 

The  availability  of  parts  at  some  future 
date  is  also  an  issue  of  obsolescence.  How 
many  integrated  circuits  will  become  obsolete 
and  impossible  to  procure,  even  at  prohibitive 
costs  in  the  future?  Or,  will  magnetic  core 
planes  be  readily  available  in  twenty  years? 

If  they  are  not  available,  commercial  computer- 
manufacturers  would  probasly  rather  give  the 
manufac turing  drawings  to  the  government  than 
be  brrdened  by  tryirg  to  make  technically  ob¬ 
solete  parts. 
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Cost  effectiveness  is  an  issue  key  to 
obsolescence.  If  hardware  trends  continue 
at  their  current  rate,  some  systems  could 
be  replaced  by  a  chip  in  the  future.  Would 
it  be  practical  to  manufacture  a  fifteen 
year  old  computer  board  when  the  entire  com¬ 
puter  could  be  replaced  by  a  chip? 

CURRENT  SOLUTIONS 

If  the  problems  referenced  in  the  pre¬ 
vious  section  are  to  be  overcome  it  is  per¬ 
haps  wise  to  study  the  current  approaches 
being  taken  by  today's  simulator  programs 
from  both  a  military  and  commercial  computer 
manufacturer1 s  point  of  view. 

1.  Long  Term  Support.  The  current 
trend  is  to  contractually  commit  a  computer 
vendor  to  support  the  product  provided  to 
the  simulator  manufacturer  for  X  years.  (X 
means  the  maximum  number  which  the  computer 
vendor  can  be  coerced  into  without  extra 
cost)  This  approach  is  unrealistic  as  it 
really  doesn't  solve  the  problem  but  rather 
shifts  the  problem  into  the  future  where 
hopefully  all  concerned  participants  are 
retired,  at  another  company,  or  another  job. 
Typically,  the  support  requirement  is  very 
vague  and  difficult  to  understand  or  pro¬ 
vide. 

The  spares  issue  is  also  an  interesting 
problem.  Under  the  current  system  only  ini¬ 
tial  spares  are  procured  with  the  simulator 
while  formal  spares  provisioning  is  per¬ 
formed  later  by  another  organization.  This 
other  organization  is  not  capable  of  deter¬ 
mining  revision  levels  on  cards  unless  they 
are  issued  an  NSN  (National  Stock  Number) 
on  a  per  revision  level  basis.  Acceptance 
is  interesting  since  the  spares  are  pro¬ 
cured  by  spec  control  drawings.  The  com¬ 
mercially  manufactured  spares  probably  won't 
meet  the  drawings  since  the  parts  are  many 
revision  levels  advanced  when  the  procure¬ 
ment  finally  takes  place. 

Typically  a  computer  supplier  or  a 
peripheral  manufacturer  is  not  interested 
in  making  boards  which  are  at  revision 
level  B  when  T  is  the  current  manufacturer's 
revision  level.  Depending  on  when  the  or¬ 
der  is  placed  the  board  may  not  have  been 
in  production  for  many  years.  Manufacturing 
to  the  old  level  would  result  in  premium 
costs  for  special  production  runs.  Some 
suppliers  have  an  automatic  upgrade  to  the 
latest  revision  level  when  a  board  is  re¬ 
turned  for  repair.  Therefore,  a  repaired 
board  may  differ  significantly  in  configura¬ 
tion  or  performance  from  like  units  in  the 
supply  system. 

Attempts  have  been  made  to  buy  the 
spares  with  the  computer  and  hope  that  they 
will  last  for  the  life  of  the  program.  This 
approach  will  work  if  estimates  are  good, 
if  there  is  enough  funding  to  procure  the 
necessary  spares  concurrently  with  each 


delivered  machine,  and  if  the  spares  can  be 
controlled  and  co-located  with  the  simulator. 
This  requires  that  the  shelf  life  for  the 
spares  exceeds  the  program  requirements  which 
may  not  be  true. 

"The  first  shall  be  like  the  last"  ap¬ 
proach  demands  that  the  previously  delivered 
systems  will  be  upgraded  to  the  configuration 
of  the  last  delivered  system  in  a  procurement. 
This  approach  also  can  work,  but  the  potential 
problems  previously  indicated  are  still  dis¬ 
tinct  possibilities.  Depending  on  the  time- 
frame  between  acquisition  of  the  first  and  the 
last  multiple  sets  of  spares,  the  spares  may  or 
may  not  be  of  value  when  the  systems  are  up¬ 
graded  . 

The  block  update  scheme  is  a  varjation  on 
"the  first  shall  be  like  the  last"  approach. 

The  first  units  are  gradually  brought  up  to 
the  following  units  configuration  as  they  are 
fielded.  For  multi-year  procurements  multiple 
upgrades  to  delivered  systems  are  a  foregone 
conclusion.  For  example,  units  1-5  will  be 
upgraded  to  look  like  units  6-11,  then  units 
1-11  will  be  again  upgraded  to  look  like  units 
12-15.  This  approach  is  workable  if  managed 
correctly  but  can  still  be  costly  depending  on 
the  timeframe  and  operational  requirements  of 
the  system. 

Perhaps  the  most  realistic  approach  which 
has  been  suggested  is  the  preplanned  replace¬ 
ment  of  computer  hardware  X  years  into  the  pro¬ 
gram.  For  example  in  a  program  with  a  twenty 
year  life  cycle  which  will  be  fielded  over  a 
period  of  seven  years  the  computer  system  would 
be  replaced  at  year  eleven  and  spares  would  be 
procured  to  last  the  additional  nine  years. 

2.  Sqftware__Compatibil_ity.  There  have 
been  two  major  approaches  recently  to  address 
the  software  compatibility  problem.  The  first 
approach  was  the  higher  order  language  mandate. 
The  second  was  use  of  the  commercial  off-the- 
shelf  computer  vendor  supplied  Operating  Sys¬ 
tem.  Software  Configuration  Management  has 
been  required  but  as  yet  has  not  met  with  the 
anticipated  results  due  to  lack  of  enforcement 
on  the  Government's  part. 

The  higher  order  language  mandate  proved 
to  be  beneficial  to  both  the  government  and 
the  manufacturers  as  Engineering  Change  Pro¬ 
posals  (ECPs)  are  not  the  great  mystery  they 
once  were  from  a  software  point  of  view.  Also, 
it  is  easier  to  train  and  obtain  people  who 
are  conversent  in  a  higher  order  language  such 
as  FORTRAN.  This  will  also  be  true  if  ADA  be¬ 
comes  the  standard  in  the  future. 

The  computer  manufacturer  supplied  OS 
software  approach  removed  the  custom  tailored 
OS  as  produced  by  the  individual  simulator 
manufacturer.  This  allowed  easier  maintenance 
and  easier  ECP  incorporation  along  with  easier 
training  of  supoort  and  operational  personnel. 
All  is  not  perfect,  however,  the  computer 
vendor  OS  is  constantly  changing  and  must  be 
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tracked  via  software  configuration  manage¬ 
ment  to  insure  that  current  software  and 
documentation  are  correctly  distributed 
among  the  development  and  field  systems. 

Another  system  used  for  controlling  the 
software  is  the  software  development  center. 
On  some  simulators  the  Software  Support 
Center  concept  of  single  point  control  of 
software  change  has  been  initiated.  Under 
this  concept,  a  single  site  is  responsible 
for  dissemination  of  all  software,  software 
updates  and  documentation.  This  ensures 
that  all  sites  will  be  running  the  same 
software.  This  does  not  alleviate  the  ob¬ 
solete  software  problem  in  regards  to  the 
computer  manufacturer's  latest  revision 
level  but  at  least  it  makes  it  more  manage¬ 
able. 

None  of  the  current  schemes  really  ad¬ 
dress  the  issue  of  the  compatibility  be¬ 
tween  the  software  on  a  simulator  system, 
which  has  been  in  the  field  for  ten  years, 
and  the  latest  release  of  a  computer  ven¬ 
dor's  software.  This  is  an  issue  which 
must  be  faced. 

3.  Obsolescence.  It  appears  that 
we  are  kidding  ourselves  as  to  the  real 
operational  life  of  the  systems.  Certain 
components  have  a  fifteen  to  twenty  year 
operational  life  but  these  systems  change 
greatly.  Of  course,  there  are  probably  ex¬ 
ceptions  which  would  dispute  this  point. 
However,  during  these  times  of  rapid  tech¬ 
nological  change  these  exceptions  will  be¬ 
come  fewer  and  fewer.  As  a  system,  the 
battleship  New  Jersey  is  radically  differ¬ 
ent  today  from  what  it  was  in  the  1940s. 

The  B- 52  Strategic  Bomber  is  today  radically 
different  from  what  it  was  in  the  1960s. 

The  average  life  of  a  computer  and  its 
associated  peripherals  from  a  manufacturer's 
viewpoint  is  about  five  years.  After  five 
years  it  is  superceded  by  a  new  generation 
and  is  considered  obsolete  from  a  technol¬ 
ogy,  price,  or  performance  point  of  view. 
This  does  not  mean  that  the  manufacturer 
will  stop  manufacturing  the  machine  because 
established  customers  generally  buy  for 
sometime  after  newer  models  are  available. 
For  example,  the  manufacturing  life  of  a 
computer  and  peripherals  would  be  from 
seven  to  ten  years,  for  the  computer  and 
three  to  five  years  for  the  peripherals  to¬ 
day.  After  ten  years  it  probably  would  not 
be  possible  to  continue  manufacturing  due 
to  low  demand  and  lack  of  availability  of 
component  parts. 

Changing  technology  is  the  biggest 
reason  for  the  demise  of  a  computer.  For 
example,  computer  memory  technology  has 
evolved  from  core  to  16K  metal  oxide  semi¬ 
conductor  chips  to  64K  chips  to  256K  chips 
and  should  evolve  to  mega' yte  chips  and 
multimegabyte  chips.  Pricing  reflects  the 


technology.  Core  is  considerably  non-  e/ger  - 
sive  than  256K  chip  technology. 

Not  only  does  the  hardware  become  obso¬ 
lete  but  the  software  becomes  obsolete.  Cur¬ 
rently  there  are  assembly  language  systems 
and  FORTRAN  systems  in  ttie  field.  In  the  fu¬ 
ture  ADA  systems  will  be  fielded.  How  diffi¬ 
cult  will  it  be  to  maintain  and  update  the  ex¬ 
isting  assembly  language  systems  which  need  to 
be  modified  due  to  changed  in  the  aircraft 
systems  in  the  future?  It  will  be  very  diffi¬ 
cult  if  not  impossible  due  to  the  lack  of  moti¬ 
vation  for  people  to  learn  the  intricacies  of 
assembly  language  programming.  Will  the  same 
thing  be  true  of  FORTRAN  based  systems  in 
twenty  years? 

RECOMMENDED  SOLUTIONS 

There  are  several  possible  solutions 
which  may  alleviate  the  problems  indicated  in 
the  previous  sections.  Whether  they  will  be 
implemented  will  depend  on  how  serious  we  are 
about  solving  the  problems.  The  solutions  as 
summarized  in  Figure  2  will  necessitate  co¬ 
operation  between  the  services,  the  logistic 
portions  of  the  services,  the  prime  contractors 
and  the  computer  manufacturers .  They  will 
necessitate  a  change  in  the  way  we  all  look 
at  a  program  such  that  we  take  our  special  in¬ 
terests  and  set  them  aside  in  favor  of  realis¬ 
tic  needs,  thus  providing  efficient,  effec¬ 
tive,  and  maintainable  systems.  Whether  this 
is  possible  or  not  only  time  will  tell.  If  it 
isn't,  we  will  all  have  failed. 

1.  The  government  must  recognize  that 
commercial  computers  and  their  associated 
spares  have  a  maximum  useful  life  of  ten  years 
and  plan  to  replace  them  with  software  compati¬ 
ble  units  in  the  ten  to  twelve  year  timeframe. 
This  requires  planning  at  the  inception  of  the 
program,  not  after  it  it  ten  years  old. 

This  would  minimize  the  spares,  obsoles¬ 
cence,  and  the  compatibility  problems. 

2.  Change  the  way  we  handle  computer 
spares  in  the  National  Supply  System  or  nan- 
date  that  the  spares  for  a  given  simulator  re¬ 
side  at  the  support  center  of  the  simulation 
system  and  be  dispursod  from  that  Inration  so 
they  they  reflect  rev  levels  of  the  cards. 

3.  Make  the  computer  suppl icr  the  depot 
level  support  unit  and  fund  it  appropriately 
to  insure  a  steady  stream  of  spares  flow 
through  to  the  simulators  and  simulator  manu¬ 
facturer  who  support  them. 

4.  Establish  a  review  process  which  in¬ 
cludes  the  computer  manufacturer  to  determine 
the  best  time  for  major  hardware  and  software 
replacements . 

6.  Simulators  must  be  maintained  at  the 
current  computer  manufacturer's  revision  of 
the  operating  system. 
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6.  Establish  a  intersnrvice/prime 
computer  manufacturer  committee  to  recom¬ 
mend  ways  to  change  the  way  we  handle  sup¬ 
port  for  simulators. 

7.  Commission  a  life  cycle  analysis 
of  real  data  on  simulators  currently  fielded 
to  determine  what  is  viable  from  the  current 
methods  and  problems  need  to  be  overcome. 


FIGURE  1 
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ABSTRACT 

The  objective  of  increased  readiness  through  training  can  be  enhanced  through  mutual  military/mdustry  efforts  to  support 
a  viable  earnings  position  Strong  financial  health  of  companies  competing  in  the  market  provides  the  resources,  knowledge 
and  systems  that  supply  advanced  technology  and  products  that  meet  military  training  objectives. 

Government  agencies  can  contribute  by  providing  clear  definitions  of  the  product  needed,  by  imposing  only  specifications 
necessary  fo  meet  acceptable  quality,  and  by  contracting  provisions  commensurate  with  program  risk  With  firm  product 
goals  and  applicable  specifications,  industry  can  minimize  risk  through  sound  planning  and  stable  performance 

Industry  can  contribute  by  developing  resources  and  systems  that  are  efficient  and  effective  in  providing  training  products. 
Capability  growth  fosters  innovativeness  in  advanced  planning  and  productiveness,  which  are  significant  to  providing  quality 
products  on  schedule  at  the  lowest  cost  possible  Industrial  growth  to  bring  this  about  is  possible  only  if  industry  is  in  a  strong 
financial  position 


The  government  s  goal  is  to  obtain  the  best  training  possible  for  the 
dollars  they  spend  Industry  must  work  with  government  agencies  and 
together  establish  how  to  reach  these  common  goals  and  find  the 
most  cost-  and  training-effective  solution  to  each  training  need 

The  government  s  needs  are  defined  by  specifications,  statements 
of  work,  funding  availability  and  weapon  IOC  dales  Industry  is 
constrained  by  the  resources,  systems,  knowledge  and 
innovativeness  they  have  at  their  command  For  these  factors  to 
culminate  in  systems  that  provide  increased  readiness  through 
training,  a  significant  amount  of  planning  and  preparation  must  occur 

To  compete  in  the  simulation  and  training  equipment  field,  industry 
must  make  the  investment  necessary  to  develop  the  skills,  provide  the 
facilities  and  the  design,  production  and  management  systems  to 
effectively  plan,  execute,  and  control  complex  programs  These 
attributes  are  assembled  over  a  long  period  of  time  at  considerable 
expense.  This  expansion  of  resources  and  systems  evolves  from 
financing  through  contracted  products  and  industry  investments  in 
research  and  development. 

Contracted  work  is  all  important,  for  it  not  only  is  the  source  of 
monies  to  build  and  sustain  capability,  but  it  provides  the  incentive  to 
pursue  further  simulation  and  training  equipment  business  Industry 
must  see  profit  opportunities  on  current  contracts  and  an  expectation 
of  continuing  contracts  to  aggressively  compete  in  the  market  Profit 
opportunities  result  from  a  well  conceived  plan  to  produce  a  defined 
product.  Ingredients  of  the  plan  include  a  thorough  description  of  the 
objective  (product),  a  sound  conceptual  approach,  a  complete 
schedule  plan,  reasonable  cost  targets  and  definition  of  potential 
risks.  With  a  sound  plan  and  good  management,  a  reasonable  profit 
can  be  achieved. 

Industry  investment  in  research  and  development  provides  the 
baseline  knowledge  to  nourish  the  innovations  that  make  needed 
products  cost-  and  training-effective  It  gives  substance  to  the 
premises  presented  as  solutions  for  development  and  design  of  the 
product.  The  payoff  is  in  enhanced  operational  readiness  resulting 
from  advanced  technology  and  effectual  products 

The  objective  of  training  is  to  maintain  the  level  of  performance 
demanded  by  modern  high  technology  The  government  s  tasks  of 
defining  training  equipment  to  meet  this  objective  continues  to 
increase  in  difficulty  In  the  Summer  1982  DoD  Acquisition 
Improvement  Program  Special  Issue  edition  of  Concepts,  authors 
Lieutenant  Colonel  Garcia  E  Morram  and  Dr  Jules  J  Bellaschi  point 
out  that.  The  United  States  has  concentrated  on  producing 
sophisticated  weapon  systems  that  have  been  reactive  lo  changes  in 
threat  and  technology  "  This  approach  has  been  maintained  by  jstng 
high  risk  technologies  in  the  development  process  An  alternative  that 


minimizes  the  resulting  cost  and  schedule  risk  is  the  use  of 
relatively  mature  technology  and  planning  for  the  incorporation  of 
advanced  technologies  after  the  system  is  developed 

Both  of  these  approaches  present  problems  in  the  definition  of 
configuration,  capability  and  quantities  of  traning  devices  to  be 
employed  As  the  weapon  system  undergoes  rapid  design  and 
technology  changes,  the  government  and  contractors  are  faced  with 
incorporating  appropriate  changes  and  reflecting  actual  operation  of 
the  aircraft  in  the  simulator  design  The  simulation  environment  is 
impacted  by  more  complex  logistics  and  the  probability  of  decreased 
equipment  availability  through  changes  and  failures  Sophistication 
and  longevity  extends  the  commitment  of  the  government  and  or  the 
contractors  This  commitment  represents  risk  that  each  seeks  to  avoid 
and  that  must  be  equitably  shared  to  achieve  the  desired  objective 

In  the  Calspan  B-l  Systems  Approach  to  Training  Technical  memo 
Analysis. I?l  of  Implications  for  B-l  Aircrew  Training,  it  is  stated  that 
.  another  important  concern  in  establishing  training  device 
requirements  is  that  the  devices,  irrespective  of  their  capabilities,  are 
used  to  their  maximum  effectiveness  As  Micheli  (1972)  states  in  his 
analysis  of  trainer  fidelity  and  training  transfer  training 
effectiveness  is  more  a  function  of  the  manner  in  which  the  trainer  is 
used  than  of  the  fidelity  of  the  trainer  The  relationship  of  weapon 
system  sophistication  and  training  equipment  definition  is  stated  in 
this  writing  as  A  common  misconception  with  respect  to  training 
is  that  the  sophistication  of  the  operational  system  and  the  duration  of 
training  (along  with  the  complexity  of  training  devices)  are  positively 
correlated.  Logically,  one  would  then  expect  there  to  be  an  inverse 
relationship  between  training  time  and  degree  of  sophistication  (i  e  . 
automation)  of  the  operational  system 

With  the  obvious  significance  of  the  need  (or  early  and  complete 
definition  of  simulator  application  and  capability,  it  is  interesting  to 
note  that  the  Calspan  B-1  SETA  Technical  Memorandum,' 11  B-1 
Aircrew  Instructional  System  Development  Final  Report.'  states.  In 
the  past  there  has  been  little  interaction  between  the  engineers  who 
design  the  simulator  systems,  the  instructional  systems  development 
personnel  who  design  the  instructional  system,  and  the  instructors 
who  will  eventually  use  the  system 

Training  device  definition  also  should  incorporate  features 
employed  by  the  instructor  to  facilitate  greater  efficiency  in  the 
learning  task  and  maximize  the  transfer  of  simulator  training  to  the 
operational  aircraft  Subsequent  to  initial  student  training,  simulators 
are  also  used  to  maintain  crew  proficiency  Definition  ot  application  is 
significant  to  the  design  of  capabilities  that  maximize  the  equipment  s 
effectiveness 

Interaction  of  these  key  factions  must  be  encouraged  to 


successfully  fulfill  the  DoD  D-50G0  2  objective  contained  in  the  section 
on  Manpower  and  Training,  New  systems  shall  be  designed  10 
minimize  both  the  numbers  and  skill  requirements  of  people  needed 
for  operation  and  support  consistent  with  system  availability 
obiectives  manpower  and  personnel  considerations 
Government  encouragement  for  the  early  involvement  of  industry  in 
the  acquisition  cycle  enhances  the  application  of  new  technology  in 
the  final  product  Early  interaction  gives  industry  an  opportunity  to 
examine  their  options  to  be  creative,  to  establish  a  sound  resources 
plan,  to  give  more  realistic  direction  to  their  research  projects  and  to 
develop  an  effective  product  plan  that  reduces  industry  risk. 

The  benefits  realized  by  the  government  from  early  industry 
involvement  can  go  beyond  reduced  risk  The  capability  of  industry  is 
expanded  through  each  commercial  application  of  training  equipment 
When  the  definition  of  training  requirements  permit  the  use  of 
commercially  developed  and  applied  technology,  government  costs 
are  reduced  Reduced  costs  of  basic  simulator  subsystems  such  as 
linkage  or  motion  bases  makes  available  more  money  to  fund  DoD 
special  needs  Analysis  of  basic  framing  needs  identifies  the  training 
objectives  that  require  high  fidelity  subsystems  Savings  resulting 
from  application  of  commercially  available  systems  can  then  be 
utilized  in  the  development  of,  for  instance.  Digital  Radar  Land  Mass 
Systems  (DRLMS).  weapon  system  delivery  systems,  etc  that 
represent  military  special  needs 

Use  of  commercial  technology  can  be  enc  xiraged  through 
eliminating  or  waiving  specifications  and  statement  of  work  elements 
that  limit  or  prohibit  its  application  The  1982  Defense  Science 
Board.'41  during  its  Summer  Study,  concluded  that,  one  particular 
training  device  has  176  top  level  military  and  Federal  specifications 
and  954  second  level  specifications,  whereas  if  it  were  bought  to 
Commercial  Practices,  some  10-12  specifications  apply  Such  a 
proliferation  of  regulations  is  expensive  to  administer,  may  eliminate 
prospective  contractors  or  subcontractors,  may  not  be  cost-effective 
to  apply  to  commercial  products  and  will  complicate  the  contracting 
process.  Interaction  of  government  and  industry  can  arrive  at  an 
acceptable  compromise  consistent  with  developing  cost-  and 
training-effective  equipment 

An  Air  Force  Systems  Command  analysis  of  the  effects  of  cost 
growth  on  system  acquisition  identified  factors  that  historically 
contribute  to  this  growth  Of  the  five  most  significant,  technical 
problems  and  impact  of  technical  advancement  have  declined  in 


seventy  Technical  complexity  as  a  factor  has  g'own  on--,  s  iqr"  , 
with  less  growth  in  the  1970s  as  systems  ber onie  inc'eas-nq1,  ---. 
sophisticated  The  analysis  concluded  that  The  big  surge-  -n  .- 
the  days  when  systems  cost  less  and  wee  herded  soone'  have  --  -- 
in  external  management  impact  and  m  tund-ng  instability 

This  study  indicates  that  government  and  industry  effort  to  define 
the  desired  product  has  shown  progress  but  othe'  disruptions  nave 
accelerated  These  disruptions  represent  a  significant  risk  to  both  the 
Short-  and  long-term  profit  objectives  of  industry  Sound  product 
planning  and  stable  performance  is  jeopardized  and  capita 
investment  is  less  attractive  when  there  is  insecurity  in  me  market 
Unfortunately  these  are  factors  normally  beyond  the  control  of 
government  agencies  responsible  for  systems  procurement  but  they 
must  be  recognized  and  dealt  with  to  minimize  the  impact  whenever 
possible 

In  order  to  establish  the  capability  to  bid  on  government 
procurements  as  a  prime  contractor,  members  of  industry  must  invest 
in  capital  equipment,  research  and  development  personnel  and 
operating  systems  Skills  required  to  develop  design,  produce  and 
deploy  an  efficient  device  are  diverse  and  can  be  obtained  only 
through  training,  experience  and  current  state-of-the  art  knowledge 
Dr  Andrew  P  Mosier  in  his  article  Enhancing  Productivity  Through 
Increased  Capital  Investment.  stales.  internal  cash  flows  are 
the  main  source  of  funds  available  to  defense  contractors  for  financing 
investments  in  new  technology  and  capital  equipment  Experience 
has  shown  that  unless  total  cash  flows  from  long-term  detense 
contracts  cover  a  substantial  portion  of  the  operating  costs,  few 
contractors  will  make  capital  investments  to  improve  their  productivity 
on  defense  programs  Both,  new  technology,  especially  in  the  areas 
ol  DoD  special  needs,  and  efficient  productivity  are  necessary  for  a 
firm  to  be  sufficiently  competitive  to  secure  and  maintain  a  military 
contract  baseline  This  process,  shown  in  Figure  1  expands  beyond  a 
regenerative  cycle  as  more  funds  become  available  to  invest  in 
advanced  simulator  technology,  new  manufacturing  processes  and 
modem  equipment 

As  a  firms  baseline  position  gains  strength,  its  competitive 
proficiency  increases  As  the  contractor  s  baseline  and  cash  flow 
grows  and  as  he  anticipates  his  share  of  the  long-term  training 
equipment  market  to  expand,  the  firm  will  optimistically  make  the 
long-term  investments  needed  to  solidify  their  competitive  position 
When  competition  sharpens,  the  government  benefits  in  a  number  of 


Figure  1  Government  Industry  Product  Development 


ways.  In  writing  about  Increasing  Competition  in  the  Acquisition 
Process."1'1  John  C  McKeown  notes  this  scope  as.  For  DnD.  the 
benefits  of  competition  extend  beyond  just  cost  reduction  to  include 
stimulation  of  innovation  not  only  in  technological  and  design  areas, 
but  also  manufacturing,  lower  unit  costs,  satisfactory  technical 
performance  (and  also  quality),  and  a  strengthened  industrial  base 

Contract  commitments  are  another  key  consideration  for  industry  in 
their  pursuit  of  military  simulator  business.  Specifications,  statement 
of  work  and  schedules  establish  the  parameters  that  define  the 
degree  of  risk  a  project  represents  Contract  terms  and  conditions 
determine  the  government/industry  participation  in  that  risk  Total  risk 
represented  by  a  project,  can  be  minimized  by  both  padicipants 
through  early  preparation  The  cost  of  initial  preparation  and 
development  is  a  small  portion  of  a  training  device 
Government/industry  interaction  to  mutually  define  the  expanse  of  the 
program  and  funding,  state-of-the-art  technology  and  schedule 
limitations  will  provide  the  framework  for  a  strong  competition  and  a 
sound  and  attainable  project 


In  conclusion,  the  interfaces  requited  to  produce  and  maintain 
training  devices  for  high  technology  systems  are  numerous  and 
complex  Mutually  acceptable  results  only  come  through  the  extensive 
eflort  of  government  and  industry  management  in  close  interaction 
Explicit  definition  of  a  training  devices  application  and  capabilities 
must  be  thoroughly  prepared  by  the  government  Specifications  musl 
be  tailored  where  commercial  off-the-shelf  products  will  meet 
performance  and  maintainability  requirements  or  where 
special/specific  capabilities  need  to  be  emphasized  to  meet  training 
requirements  Industry  can  help  identify  such  areas  and  aid  in  the 
most  effective  use  of  available  funds  if  brought  into  the  procurement 
cycle  early  enough  Timeliness  of  funding  by  the  government 
motivates  industry  to  respond  with  innovation  and  cost-saving 
productivity  to  provide  state-of-the-art  training  devices  whne 
maintaining  earnings  at  an  acceptable  level  Industries  that  are  not 
making  a  profit  will  not  make  the  long-term  investments  in  technology 
and  facilities  that  are  necessary  to  support  government  agencies  in 
their  effort  to  gain  increased  readiness  through  training 


Identifying  risk  and  contractor  investment  associated  with  a  project 
gives  a  firm  basis  for  establishing  a  profit  objective  and  contract  type 
As  risk  is  reduced,  the  contract  type  should  move  from  cost 
reimbursement  toward  fixed  price  A  profit  objective  should  be 
structured  to  recognize  assumption  of  risk,  contractor  investment  and 
performance.  Defense  Acquisition  Regulation  (DAR)  Guidelines  set 
forth  ground  rules  for  the  application  of  specific  contract  types 

The  contract  type  should  be  selected  to  provide  a  maximum 
incentive  for  the  contractor  to  perform  to  the  desired  level  in  the  most 
economical  manner  commensurate  with  the  circumstances  of  the 
particular  procurement  (Figure  2)  Fixed  price  contracts  normally 
provide  the  most  incentive  for  contractor  performance  However, 
degree  of  effective  competition,  extent  and  nature  of  contract 
performance,  level  of  contractor  experience,  relationship  of  contract 
requirements  to  state-of-the-art  perceived  accuracy  of  the  quoted 
price,  degree  of  financial  risk  and  financial  position  of  the  contractor 
can  influence  the  decision  to  select  a  contract  type  other  than  firm 
fixed  price 

While  the  profit  motive  induces  contractors  to  commit  resources 
cash  flow  makes  Ihese  resources  available  Cash  flow  comes  horn 
progress  payments  and  sales  Recently,  the  government  has 
recognized  the  contractor  s  need  for  cash  flow  relief  Provisions  have 
been  made  for  increased  progress  payments  When  applicable, 
flexible  progress  payments  can  be  implemented  and  milestone  billings 
may  be  used  to  supplement  progress  payments  These  cash  flow 
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reducing  techniques  also  have  aided  contractors  in  reducing  the 
amount  of  interest  expense,  an  unallowable  cost,  they  accrue  in 
performing  government  contracts  These  provisions  should  be  a 
significant  element  in  the  contracting  process  and  must  be  applied  in 
an  effective  manner  to  maintain  fhe  financial  health  of  military 
contractors. 
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Figure  2  Contract  Selection  Considerations 
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abstract 

Tn  order  to  obtain  the  enhanced  testing  capability  required  to  test  sophisticated 
trainer  software  and  to  ensure  the  quality  of  test  documentation,  AAT  has  developed  an  auto¬ 
mated  software  testing  system.  Tts  advantages  include: 

1.  Automatic  production  of  all  test  documentation. 

2.  Guaranteed  agreement  of  the  values  inserted  into  or  read  from  memory  during  a  test 
with  test  documentation. 

3.  Guaranteed  consistency  of  test  Hocunentat i on  with  other  documents. 

4.  The  ability  to  compare  or  insert  repetitively  large  buffers  of  data;  testing  is  no 
longer  subject  to  the  limitations  of  hand-insertion  of  data,  or  visual  comparison  of 
data . 

5.  Simultaneous  updaLing  of  both  test  and  test  documentation  through  the  editing  of 
test  disc  files. 

b.  The  ability  to  save  large  areas  of  memory  for  future  comparisons,  a  feature 
especially  useful  for  software  integration. 

This  paper  examines  the  AAT  software  package  in  detail. 


INTRODUCTION 

Thorough  testing  is  the  only  way  to  ensure 
the  error-free  operation  of  trainer  software. 
Moreover,  the  ever  increasing  complexity  of 
trainer  software,  as  military  systems  grow  in 
sophistication,  demands  a  corresponding  Increase 
in  the  amount  and  effectiveness  of  software 
testing. 

Tn  view  of  this  situation,  it  is  not 
surprising  that  software  tesing  represents  a 
substantial  financial  burden  to  the  development 
process.  This  burden  is  further  increased  by 
software  standards  which  require  thorough  docu¬ 
mentation  of  testing,  such  as  MTL-STD- 1  b44 .  Tn 
such  casen,  the  problem  of  ensuring  that  the 
documentation  accurate’y  reflects  the  testing 
process  can  he  difficult. 

AAT  has  solved  the  documentation  problem,  and 
enormously  eased  the  burden  of  testing  as  a 
whole,  by  developing  the  software  package  pre¬ 
sented  in  this  paper.  The  package  represents  a 
rather  general,  1  anguage- 1 ndependent  approach  to 
the  testing  problem  which  can  be  adapted  to  the 
needs  of  almost  any  software  devnlopment  effort. 


demands  thorough  documentation  of  all  development 
stages,  including  testing. 


In  this  paper,  we  are  principally  concerned 
with  the  Computer  Program  Test  Procedures  Report 
( CPTP)  required  bv  MTL-STD- 1 b44 .  However,  the 
AAT  package  also  produces  the  following  MIL- 
STD-lb44  documents: 


Data  Base  Design  Document  (DBDD) 

Program  Design  Spec i f i cat  ion  (PDS) 
Program  Description  Document  (PDD) 


Indeed,  it  is  the  commonality  of  manv 
components  of  the  testing  system  with  the  docu¬ 
mentation  system  which  ensures  the  consistency  of 
the  CPTP  with  the  other  documents. 


The  AAT  package  was  developed  on  the  general 
purpose  computer  central  to  the  2GBS  project,  the 
SKI,  32/K7  minicomputer.  It  requires  approxi¬ 
mately  bOK  of  32-hit.  core  and  substantial  disc 
space.  (The  amount  of  disc  space  required 
depends  on  the  size  of  the  particular  software 
project).  Tt  is  written  almost  entirely  in 
structured  FORTRAN,  SF.L  version  7  7  -v . 


BACKGROUND  OF  THF  SOFTWARE  TF.STTNG  SYSTEM 

The  an  ton  tied  software  testing  system 
described  in  this  paper  Is  part  of  a  <!»velopment 
and  documentation  package  successfully  used  bv 
AAT  in  the  development  of  the  ?0BC  Pierside 
Combat  System  Team  Trainer.  Tt.  is  important,  to 
note  that  ?DBS  software  development  was  subject 
to  the  requirements  of  MT L-STD- ! b44 ,  which 


DF.FTN1NG  A  TEST  TN  THF 
AUTOMAT F.D  TESTING  F.NVT  RONMF.NT 

The  testing  approach  taken  by  the  automated 
testing  system  is  "black  box  testing".  That  is, 
the  testing  system  neither  knows  nor  cares  how  a 
program  works;  it  only  tests  whether  or  not  the 
outputs  of  the  program  are  correct  for  given  sets 
of  inputs.  of  course,  if  problems  are  detected 
during  such  testing,  it  mav  he  necessary  to  use 


367 


other  methods  to  loro  to  the  source  of  the 
t  rouble . 

In  order  to  associate  inputs  with  their 
corresponding  outputs,  tests  for  the  -intonate  I 
system  are  defined  .is  1  series  of  steps.  Tn  each 
step,  inputs  are  made  to  the  program  being  tested 
bv  means  of  a  specified  operator  action,  known  as 
the  "control  action”.  The  test  operator  then 
checks  that  the  resulting  outputs  of  the  program 
are  as  expected;  if  they  are  not,  a  failure  has 
occurred.  The  expected  outputs  are  known  as  the 
"expected  results"  of  the  test  step  and  are  part 
of  t he  step  definition. 

Control  actions  may  be  either  "textual"  or 
"numerical".  Tn  a  textual  control  action,  the 
operator  is  asked  to  throw  a  switch,  make  a 
tableau  entry,  or  do  anything  else  which  dn°s  not 
directly  involve  program  symbols.  In  a  numerical 
control  action,  the  test  operator  is  instructed 
to  set  specified  program  symbols  to  specified 
va  l  ties , 

Similarly,  expected  results  nnv  he  either 
textual  or  numerical.  Tn  a  textual  expected 
result,  the  operator  is  asked  to  make  an 
observation  not  directlv  involving  program 
symbols  (e.g.,  a  light  is  on).  Tn  a  numerical 
expected  result,  the  operator  is  asked  to  verifv 
that  specified  program  symbols  have  specified 
values  within  specified  tolerances. 

It  should  be  noted  that  in  defining  tests  for 
the  automated  testing  system,  there  is  no  limit 
to  the  number  of  symbols  and/or  values  which  nav 
be  specified  in  a  single  numerical  control  action 
or  expected  result.  Value  repetition  counts  and 
symbol  subscripts  are  available  to  facilitate  the 
definition  of  large  data  buffers  for  insertion  or 
comparison . 

often  the  execution  of  the  program  being 
tested  is  suspended  while  the  operator  performs 
control  actions  or  verifies  expected  results; 
however,  this  is  not  a  requirement.  Instructions 
for  suspending  or  resuming  program  execution  nav 
be  placed  in  the  test  as  textual  control  actions. 
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ADVANTAGES  OF  THE 
AUTOMATED  SOFTWARE  TESTING  SYSTEM 

The  automated  testing  system  described  above 
streamlines  the  performance  of  black-box  software 
tests  based  on  prog ran- symbol  values.  It  has  the 
following  considerable  advantages  over  manual 
me  t  hod  s  : 

1.  Because  tests  are  stored  in  disc  files 
that  are  read  by  the  testing  system,  the 
same  numerical  operations  can  be  repeated 
over  and  over  again,  the  tests  are 
reproducible . 

2.  The  abilitv  to  insert  or  compare  large 
buffers  of  data  is  another  natural  con¬ 
sequence  of  disc  file  test  definition. 

1.  Comparisons  are  automatically  performed 
taking  tolerances  into  account.  Memory 
insertions  are  also  automatic. 

A.  Complete  test  reports,  highlighting 
failures  and  showing  deviations  from 
expected  results  can  be  produced  in  hard 
copy  form  at  the  convenience  of  the  test 
operator. 

5.  The  same  test  definitions  used  to  run  the 
test  are  used  to  automatically  generate 
the  CPTP  docuent.  This  ensures  that  the 
document  accurately  reflects  the  testing 
process. 

6.  Because  the  CPTP  and  other  documents  are 
all  based  on  the  same  central  data  base 


file,  the  consistency  of  the  CPTP  with 
other  documents  is  assured. 

7.  The  ability  of  the  testing  svstem  to  save 
present  actual  results  for  future  com¬ 
parisons  provides  a  convenient  method  of 
monitoring  changes  in  computer  memory  as 
new  versions  of  software  are  tested. 

Under  the  present  svstem,  the  program  being 
tested  and  the  testing  programs  are  together  hv 
the  aul omal 1 c a  1 1 v  generated  global  maps  and 
FORTRAN  specification  statements  that  serve  to 
associate  symbols  with  memory  locations.  How¬ 
ever,  it  should  be  emphasized  that  FORTRAN  is 
merely  incidental  to  the  necessary  task  of 
linking  symbols  with  addresses;  anv  automatic 
method  of  doing  this  would  serve  equally  well. 
The  automatic  testing  approach  is  reallv  a 
1 anguage- i ndependent  testing  method  that  can  be 
used  whenever  svmbol-based  black  box  testing  is 
appropriate , 
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ABSTRACT 

Management  of  a  software  development  project  Is  typically  characterized  by.  a  lack  of 
control  and  poor  projections.  Status  reports  are  notoriously  Inaccurate;  worse  yet,  the 
prerequisite  software  audits  drain  development  resources  from  the  design  effort. 

This  paper  describes  an  automated  procedure  for  performing  software  audits  and  gen¬ 
erating  status  reports.  This  procedure  reduces  the  time  required  for  both  tasks 
significantly,  and  makes  status  reports  available  upon  demand.  Timely  status  reports  furnish 
management  with  an  early  warning  of  problem  areas  so  that  project  control  can  be  exercised. 
For  example,  resources  may  be  reallocated  or  additional  resources  employed  where  these  prob¬ 
lems  are  identified. 

The  Automatic  Audit  Information  System  for  Software  Development  (AAIS)  procedure  has 
been  Implemented  by  AAI  Corporation  for  the  development  of  Device  20B5.  It  Is  based  upon 
the  following  concepts: 

*  A  central  software  development  library 

*  Software  development  milestones  and  criteria 

*  Functional  hierarchies  r\  , 

*  A  development  scoreboard. 

AAIS  provides  the  20B5  management  with  close  project  control  by  means  of  timely  audits  and 
concise  status  reporting.^ 


Introduction 

The  technological  revolutions  that  have 
yielded  more  powerful  and  sophisticated  computer 
systems  have  encouraged  defense  contracts  for 
more  complex  and  higher  fidelity  training 
systems.  As  trainer  specifications  Incorporate 
the  new  technology,  designs  such  as  those 
Incorporated  In  Device  20B5  are  often  required 
for  effective  simulation  and  stimulation  for  team 
training.  Team  training  Implies  a  multi-task 
environment  to  support  several  operational  equip¬ 
ments  which  are  typically  employed  In  cooperative 
roles.  In  this  case,  the  simulation  software 
developed  exceeds  the  scope  of  medium-complexity 
software  systems  of  the  past,  and  becomes  one  of 
the  complex  software  systems  of  the  present.  The 
development  effort  for  complex  systems  is  larger, 
by  an  order  of  magnitude,  and  must  be  carefully 
controlled  In  order  to  ensure  Its  successful 
completion.  This  control  must  be  implemented 
with  concise  and  timely  status  reporting. 
However,  the  preparation  of  status  reports  must 
not  Interfere  with  the  critical  milestones  estab¬ 
lished  for  design  personnel.  In  addition,  the 
information  retrieved,  analyzed  and  presented 
must  accurately  reflect  the  current  status  of  the 
software  development  effort. 


variances.  The  various  report  formats  allow  the 
manager  to  selectively  scan  the  Information  and 
extract  those  Items  which  are  pertinent  for 
analysis.  The  reports  highlight  milestone  com¬ 
pletion  with  regard  to  budget  and  schedule,  which 
Is  of  primary  concern  to  management  personnel. 

The  automated  procedures  Incorporated  In  the 
AAIS  program  are  controlled  by  criteria  estab¬ 
lished  during  the  Infancy  of  the  software 
development  effort.  These  criteria  are  derived 
from  contractual  requirements  such  as  those  pre¬ 
sented  in  MIL- STD- 1644.  In  addition,  documenta¬ 
tion  defined  by  the  Data  Item  Descriptions 
(DIDs),  In  particular,  the  Program  Design 
Specification  (PDS),  assist  In  formulating  the 
Software  Work  Breakdown  Structure  (SWWBS)  which 
becomes  an  Integral  foundation  for  the  command 
and  control  facilities  used  to  drive  the  AAIS 
program. 

Design  of  the  AAIS 

The  Automatic  Audit  Information  System  for 
Software  Development  (AAIS)  procedure  has  evolved 
as  a  result  of  continuing  efforts  at  AAI  to  track 
and  control  software  development  for  training 
devices.  The  salient  features  which  have  emerged 
are: 


The  Automatic  Audit  Information  System  for 
Software  Development  (AAIS)  procedure  has  been 
developed  to  efficiently  track  software  develop¬ 
ment  with  a  minimum  of  design  personnel 
interaction.  The  progress  reports  which  are 
generated,  provide  both  management  and  design 
personnel  the  information  needed  to  monitor  soft¬ 
ware  progress  and  identify  schedule  and  cost 


Software  hierarchies 
Milestone  completion  criteria 
Software  development  scoreboard 
Centralized  on-line  development  library 
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*  Software  module  formats 

*  Automated  audit  and  report  procedure. 

Each  of  the  above  features  is  described  below 
In  the  context  of  Its  application  to  the  develop¬ 
ment  of  Device  20B5.  Figure  1  presents  a  diagram 
of  the  AAIS  concept. 


The  contract  sponsor  requires  a  hlerarchal 
listing  of  software  modules  for  each  functional 
area  defined  In  the  Program  Performance  Speci¬ 
fication  (PPS)  and  detailed  In  the  Program  Design 
Specification  (PDS).  The  sample  hierarchy  given 
In  Figure  2  Indicates  naming  conventions  and  the 
control  structure  defined  for  the  function. 
These  hierarchies  are  entered  and  maintained  in 
an  encoded  form,  known  as  the  Software  Work 
Breakdown  Structure  (SWWBS),  on  the  computer 
storage  media.  The  stored  files  represent  a 
means  of  addressing  a  functional  area  down  to  the 
module  level. 

Milestones  are  provided  by  the  customer  in 
the  form  of  contractual  delivery  and  report 
dates.  These  dates  Imply  that  software  managers 
must  develop  the  necessary  and  detailed  software 
development  milestones  required  to  meet  the 
contract  delivery  dates.  This  effort  amounts  to 
critical  path  scheduling  of  available  personnel 
within  time  and  computer  availability  con¬ 
straints.  Five  (5)  software  development 
milestones  are  defined  as  follows: 


Module  design 
Module  coding 
Module  test  driver  design 
Module  testing 
Function  testing. 


1.2. 2. 5. 2  ASW  ENVIRONMENT  ( SONOBUOY  A 

AN/S0S-S6  SONAR)  FUNCTION  SWWBS 
(PDS  SECTION:  1.1.2.S.2) 

COMPUTER:  OWNSHIP 


SEL  TASK:  NEW 

N02NEXEC 

NE4EXF.C 


NE5WKMSK 

NE6WMRF.F 

NE6WHERE 

NE6STATS 

NE6STREN 

NE5D0PRT 

NE50PL56 

NEftINTRP 

NCZINTP2 

NE5SNBW0 

NE50PRLS 

NE60PLRT 

NCZINTP2 

NE5AMBNS 

NE5KBSHD 

NE5TCNIM 

NE6HARME 

XDZDSCIO 

NE6RECRD 

XDZDSCIO 

NE6VALID 

XDZDSCIO 

NCZBSRCH 

NE5RVERB 


NEW  TASK  EXECUTIVE 
ASW  ENVIRONMENT  (SONOBUOY 
&  SOS-SB)  EXEC 
WAKE  MASKING  CONTROL 
WAKE  MASKING  DATA  FORMAT 
WAKF.  SEGMENT  POSITIONS 
SENSOR  STATUS  AND  WAKE 
POSITION 

WAKE  SEGMENT  STRENGTH 
DOPPLER  RATIO 
S0S-S6  OCEAN  PROPAGATION 
LOSS  CONTROL 
PROPAGATION  CONTROL 
TWO-WAY  INTERPOLATION 
SONOBUOY  WASHOVER 
OCEAN  PROPAGATION  LOSS 
CONTROL 

OCEAN  PROPAGATION  LOSS 
RETRIEVAL 

TWO-WAY  INTERPOLATION 
AMBIENT  NOISE 
KELP  BED  SHADOWING 
TCNI  MANAGEMENT  CONTROL 
HARMONIC  FAMILY  DATA 
DISC  I/O  OUEUING 
RECORD  NUMBER 
DISC  I/O  QUEUING 
VALIDITY  CHECK 
DISC  I/O  OUEUING 
BINARY  SEARCH 
REVERBERATION 


Figure  2.  Sample  Function  Hierarchy 


The  completion  criteria  for  each  milestone  is 
provided  by  project  management  and  software  team 
personnel.  These  criteria  identify  development 
requirements  for  the  completion  of  each  mile¬ 
stone.  Completion  of  each  milestone  Is  predicted 
upon  the  existence  of  a  critical  item  In  the 
module  file,  e.g.,  the  existence  of  the  high 
level  language  (code)  satisfies  the  coding  com¬ 
pletion  criteria. 

A  development  scoreboard  is  formed  by  the 
combination  of  a  function  hierarchy  and  software 
development  milestones.  A  matrix  of  values  can 
be  obtained  if  a  value  is  assigned  to  each  mile¬ 
stone  and  to  each  module  In  the  hierarchy.  A 
milestone  value  represents  a  specific  development 
weighting  factor  whereas  a  module  value  can  be 
thought  of  as  a  design  complexity  factor  for  the 
design  of  the  module.  The  resulting  matrix  ele¬ 
ments  are  defined  by  computing  the  product  of 
each  combination  of  milestone  value  and  module 
value.  Milestones  which  are  not  completed  are 
assigned  a  value  of  zero.  The  significance 
regarding  the  Implications  of  this  approach 
should  not  be  overlooked.  Applying  a  set  of 
weighted  values  to  milestones  Is  in  effect  a 
means  for  budgeting  the  time  required  to  fulfill 
each  milestone  as  a  fraction  of  the  total  time 
for  an  average  module.  At  a  modular  level,  this 
budgeting  effort  Is  much  more  precise  than  at  a 
functional  level.  Typical  estimates  are  avail¬ 
able  from  the  Pie  chart  illustrated  In  Figure  1 
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***************  2DB5  MODULE  FILE  **************** 
***************  MODULE  CONTROL  DATA  ************* 


and  in  terns  of  Industry  standards  for  lines  of 
code  per  programmer  day.  On  the  other  hand, 
nodule  weights  are  derived  by  allocating  a  total 
value  to  each  function  based  upon  perceived 
difficulty,  and  In  turn,  rationing  this  total 
among  all  modules  of  the  associated  function. 
The  total  value  attributed  to  the  function  rep¬ 
resents  the  amount  of  effort  budgeted  for  the 
function.  The  ratio  of  the  sum  of  all  the  matrix 
values  to  the  total  possible  sum  for  the  matrix 
Is  Interpreted  as  the  reportable  completion 
percentage  of  the  function  at  the  time  of  audit. 


Figure  1.  Function  Development  Costing 


A  centralized,  computer-resident  software 
development  library  makes  possible  automatic 
auditing  of  the  software  Inventory.  All  modules 
are  readily  accessible  and  maintainable. 
Although  modules  are  developed  by  Individual 
designers,  a  module  belongs  to  the  project  and 
resides  In  the  control  library.  This  feature  is 
essential  to  project  control,  since  all  modules 
must  be  available  for  auditing  purposes. 

All  modules  in  the  central  library  are 
entered  according  to  the  format  developed  for 
Device  20B5.  Templates  are  provided  to  designers 
and  data  entry  personnel  to  simplify  the  process 
and  Insure  standardization.  The  object  of  the 
format  Is  to  capture  the  high  level  language 
along  with  design  summaries  and  Internal  docu¬ 
mentation  for  the  module,  as  depicted  in  Figure 
4.  These  module  ftles  contain  sufficient 
information  for  automatic  generation  of  con¬ 
tractual  reports  such  as  the  PDS,  Module  files 
represent  self-contained  repositories  of 
Information  concerning  the  embedded  execution 
language  (FORTRAN)  routine.  This  Information 
also  Includes  a  module  test  procedure  (a  driver 
description)  as  well  as  configuration  management 
data  for  the  code  and  test  procedure. 
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*  MODULE  NAME:  SA6SAADJ 

*  MODULE  TITLE:  SONOBIJOY  SONAR  AMPLITUDE 

ADJUSTMENT 

*  MODULE  SECURITY  CLASSIFICATION:  11 

*  MODULE  PART  NUMBER:  58 18 1-7-OS 1-36406-U 

*  PROCRAMMER:  OABROWN 


***************  p ■) p  DATA  *********************** 

*  MODULE  PROCESSING:  SA6SAADJ  WILL  COMPUTE  THE  * 

VESSEL  SONAR  AND  INTER- 

*  FERINO  SONOBUOY  AMPLITUDE 

*  DEGRADATION  FACTORS  OF  THE 

*  RESULTING  SIGNAL  ENVELOPE 

*  WITH  RESPECT  TO  EACH  OF 

*  FOUR  POSSIBLE  SONOBIIOYS  ON 

*  CHANNEL.  THE  DEGRADATION 

*  FACTORS  . . . 

**************  PROGRAM  DESIGN  LANCUAGE  ********* 

*PDL-  1  DO  FOR  EACH  VESSEL  TARGET  SLOT 
*PDL-  2  IF  THE  VESSEL  SONAR  PING  INDICATOR  IS 
SET  TO 

*PDL-  3  TRUE  THEN 

*PDL-  4  DO  FOR  EACH  S0R-I7  CHANNEL 

***************  MODULE  REVISION  HISTORY  ********* 

*  0000  06/18/83  GAB  INTEGRATED 

***************  test  PROCEDURE  REVISION  HISTORY  * 

*  0000  06/18/83  GAB  INTEGRATED 

***************  MODULE  TEST  PROCEDURE  *********** 
C  PROGRAM  DRIVER 

C  REAL  *  4  ERVALII  1-2.0/ ,  TOLER  1 1  /0.001/ 

C  CALL  BEGINMTP  (MODULE) 

C  OINSHIPB  -  1 

C  AASPTNGL  -  .TRUE. 

C  CALL  SA6SAADJ 

***************  CODE  **************************** 

SUBROUTINE  SA6SAADJ 
INCLUDE  SONOB 
INCLUDE  SONOBP 

* 

************************************************* 

*PDL-  1  DO  FOR  EACH  VESSEL  TARGET  SLOT 

************************************************* 

* 

DO  I  -  1,  OINSHIPB 

* 

************************************************* 
*PDL-  2  IF  THE  VESSEL  SONAR  PING  INDICATOR  IS 
SET  TO 

*PDL-  3  TRUE  THEN 

************************************************* 

* 

IF  (  AASPINGL  (I)  )  THEN 

Figure  4.  Module  File  Template 


Finally,  based  upon  all  of  the  above  features, 
an  automated  auditing  and  status  reporting  pro¬ 
cedure  is  employed  to  control  software  develop¬ 
ment.  This  procedure  is  driven  by  the  manager's 
selection  of  one  or  more  function  hierarchies. 
For  each  function  selected,  the  associated 
hierarchy  is  used  to  provide  the  module  names  and 
corresponding  weights.  The  actual  modules  in  the 


central  library  are  automatically  Inspected  and 
the  criteria  la  applied  to  the  retrieved  Informa¬ 
tion  such  that  a  set  of  reports  can  be  prepared. 
Both  module  and  function  summations  are  computed, 
along  with  their  respective  percentages  of 
completion.  Discrepancies  In  nodule  file  formats 
are  dlscernable  from  the  resulting  reports,  pro¬ 
viding  quality  control  for  both  audits  and  module 
files.  History  files  are  updated  to  automati¬ 
cally  record  the  current  audit  statistics.  In 
addition  to  producing  status  reports.  Information 
reports  are  conveniently  produced  for  review  by 
software  designers.  These  summaries  provide 
highly  useful  organizational  information. 

AA1S  Outputs:  Status  Reports 

The  AAIS  program  generates  seven  (7)  distinc¬ 
tive  report  formats  for  review  by  both  managers 
and  design  personnel.  The  report  formats  contain 
the  following  Information: 

(1)  Functional  Design  History  and  Resource 
Utilization  by  module 

(2)  Functional  Development  Status  by  module 


(3)  Functional  Milestone  Status  by  module 

(4)  Functional  Hierarchy  by  module 

(5)  Functional  Configuration  Status  by 
module 

(6)  Milestone  Summary  by  function 

(7)  Cost  Performance  Summary  by  work  order 
(charge)  number 

Report  formats  (3),  (6)  and  (7)  are  provided  as 
the  basic  set  of  status  outputs  to  the  manager. 
These  summaries  describe  software  development 
status  In  terms  of  milestones  and  cost.  Report 
formats  (1),  (2),  (4)  and  (5)  provide  additional 
organizational  information  to  the  designer. 
These  reports  highlight  module  design  status  In 
terms  of  documentation  requirements  and  configu¬ 
ration  management  data. 

The  Functional  Design  History  and  Resource 
Utilization  report  lists,  on  a  module  basis, 
development  and  testing  revision  histories. 
Figure  5  depicts  a  sample  report  format. 
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COMPUTER 

SEL 

TASK 

MODULE 

PROG. 

DISC 

ENTRY 

MODULE 

MODULE 

TEST 

TEST 

WORST 

WORST 

DATE 

REV. 

REV. 

REV. 

REV. 

CASE 

CASE 

DATE 

LEVEL 

DATE 

LEVEL 

TIME 

MF.M. 

OWNSHIP 

NEW 

TASK 

NCZBSRCH 

FINLEY 

STS20B5E 

4/12/82 

12/14/82 

0000 

12/14/82 

0000 

30 

280 

OWNSHIP 

NEW 

TASK 

NCZINTP2 

FINLEY 

STS20B5E 

4/13/82 

06/03/82 

0001 

06/03/83 

0001 

8 

496 

OWNSHIP 

NEW 

TASK 

NE4EXEC 

FINLEY 

STS20B5E 

3/4/82 

03/10/83 

0000 

03/10/83 

0000 

816 

1160 

OWNSHIP 

NEW 

TASK 

NE5AMBNS 

FINLEY 

STS20B5E 

2/22/82 

05/11/83 

0001 

ERR 

0001 

300 

208 

OWNSHIP 

NEW 

TASK 

NE5DOPRT 

FINLEY 

STS20B5E 

2/22/82 

01/11/83 

0002 

01/11/83 

0002 

5 

200 

OWNSHIP 

NEW 

TASK 

NE5KBSHD 

FINLEY 

STS20B5E 

2/19/82 

03/10/83 

0000 

03/10/83 

0000 

250 

712 

OWNSHIP 

NEW 

TASK 

NE50PL56 

FINLEY 

STS20B5E 

04/13/82 

03/02/83 

0000 

03/02/83 

0000 

250 

1088 

OWNSHIP 

NEW 

TASK 

NE50PRLS 

FINLEY 

STS20B5E 

4/14/82 

03/10/83 

0000 

03/10/83 

0000 

100 

608 

OWNSHIP 

NEW 

TASK 

NE5RVERB 

FINLEY 

STS20B5E 

09/27/82 

05/19/83 

0001 

05/19/83 

0001 

100 

576 

OWNSHIP 

NEW 

TASK 

NE5SNBW0 

FINLEY 

STS20B5E 

2/19/82 

03/01/83 

0000 

03/01/83 

0000 

30 

144 

OWNSHIP 

NEW 

TASK 

NE5TCNIM 

FINLEY 

STS20B5E 

03/05/82 

04/11/83 

0003 

04/11/83 

0003 

300 

840 

OWNSHIP 

NEW 

TASK 

NE5WKMSK 

FINLEY 

STS20B5E 

07/26/82 

02/22/83 

0000 

02/22/83 

0000 

100 

1040 

OWNSHIP 

NEW 

TASK 

NE6HARME 

FINLEY 

STS20B5E 

16JUN82 

04/12/83 

0002 

04/12/83 

0002 

10 

432 

OWNSHIP 

NEW 

TASK 

NE6INTRP 

FINLEY 

STS20B5E 

04/15/82 

06/02/83 

0001 

06/02/83 

0001 

2 

368 

OWNSHIP 

NEW 

TASK 

NE60PLRT 

FINLEY 

STS20B5E 

04/14/82 

03/21/83 

0000 

03/21/83 

0000 

30 

336 

OWNSHIP 

NEW 

TASK 

NE6RECRD 

FINLEY 

STS20B5E 

05/24/82 

05/12/83 

0002 

05/12/83 

0002 

100 

312 

OWNSHIP 

NEW 

TASK 

NE6 STATS 

FINLEY 

STS20B5E 

07/23/82 

02/21/83 

0000 
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The  Functional  Development  Status  report 
denotes,  on  a  module  basis,  the  current  state  of 
design  for  a  function.  The  design  states  are 
categorized  by  the  major  milestones  assigned  to  a 
module.  In  this  way,  the  designer  can  quickly 


3. 3. 2. 5. 2  ASW  ENVIRONMENT  (S0N08U0Y  £  SQS-56) 


assess  the  overall  development  state  of  a  func¬ 
tion  hierarchy  and  identify  Incomplete  or 
incorrect  data  entries.  Figure  6  shows  a 
Functional  Development  Status  report. 
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Figure  6.  Function  Development  Status  Report 
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The  Functional  Milestone  Status  report 
depicts,  on  a  module  basis,  the  milestone  matrix 
for  a  function  hierarchy.  This  matrix  represents 
the  reportable  status  of  the  function  at  the  time 


of  audit.  The  matrix  values  are  displayed  for 
each  milestone  and  each  module.  Figure  7  Illus¬ 
trates  a  Functional  Milestone  Status  report. 
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Figure  7.  Functional  Milestone  Status  Report 
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The  Functional  Hierarchy  report  reiterates 
the  module  breakout  defined  for  the  PDS  and 
associates  module  completion  codes  with  each 


module  name.  The  module  completion  rode  rep¬ 
resents  an  Index  of  the  current  reportable  status 
of  the  module.  Figure  8  exemplifies  the  Func¬ 
tional  Hierarchy  report. 
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Figure  8.  Functional  Hierarchy  Report 
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The  Functional  Configuration  Status  report 
Illustrates  the  current  Integration  state  of  each 
nodule  of  the  function.  The  module  Is  listed 


20B5  SOFTWARE  STATUS  REPORT 
FOR 

3. 3. 2. 5. 2  ASW  ENVIRONMENT  (SONOBUOY  &  SOS-56) 


under  the  appropriate  control  library  designa 
tlon.  Figure  9  provides  a  sample  report. 
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Figure  9.  Function  Configuration  Status  Report 


The  Milestone  Summary  report  lists,  by  func-  with  a  snapshot  of  the  current  software  design 
tion,  the  actual  and  scheduled  budget  values  and  status  in  terras  of  the  milestones  established, 
associated  variances  from  subsequently  scheduled  Figure  in  presents  a  sample  Milestone  Summary 
audit  dates.  This  report  provides  the  manager  report  for  Device  20B5. 
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91.9 

100.0 

100.0 

-24 

24 

3. 3. 2. 3. 2 

ACTIVE  ACOUSTICS 
(SOS- 56) 

125641 

636 

534 

84.0 

78.0 

93.0 

38 

57 

3. 3. 2. 3. 3 

PASSIVE  ACOUSTICS 
(AN/ SOS- 56  TASK) 

125641 

1814 

1424 

78.5 

81.0 

90.0 

-45 

208 

3. 3. 2. 3.4 

PASSIVE  BUFFER 

125641 

46 

0 

.0 

92.0 

100.0 

-42 

46 

3. 3. 2. 3. 5 

ASW  SONAR  I/O 

125611 

204 

0 

.0 

92.0 

100.0 

-187 

204 

3. 3. 2. 4. 2 

ACTIVE  ACOUSTICS 
(SONOBUOY) 

125641 

908 

650 

71.6 

74.0 

93.0 

-21 

194 

3. 3. 2. 4. 3 

LAMPS  SONOBUOY 
ACOUSTICS 

125641 

1872 

1315 

70.2 

100.0 

100.0 

-557 

557 

3. 3. 2. 4. 4 

LAMPS  SONOBUOY 
ACOUSTICS  I/O 

125611 

204 

0 

.0 

92.0 

100.0 

-187 

204 

3. 3. 2. 5.1 

SONOBUOY  AND 

SOS-56  RELATIVES 

125611 

1158 

1110 

95.9 

95.0 

100.0 

10 

48 

3. 3. 2. 5. 2 

ASW  ENVIRONMENT 
(SONO  &  SOS-56) 

125611 

1724 

1185 

68.7 

100.0 

100.0 

-539 

539 

3. 3. 2. 6.1 

OWNSHIP  DISC  I/O 

125611 

468 

399 

85.3 

94.0 

100.0 

-40 

69 

3. 3. 2. 7.1 

OWNSHIP  MONITOR 

125611 

204 

204 

100.0 

93.0 

100.0 

15 

0 

3. 3. 2. 7. 2 

REAL-TIME 

EXECUTIVES 

125611 

476 

476 

100.0 

93.0 

100.0 

34 

0 

3. 3. 2. 8.1 

DDL  I/O 

125611 

432 

144 

33.3 

93.0 

100.0 

-253 

288 

3. 3. 2. 8. 2 

AN/ SQS-56  PING 
PROCESSING 

125641 

1978 

1252 

63.3 

80.0 

92.0 

-330 

567 

3. 3. 2. 8. 3 

INTERBUS  LINK 
HANDLER 

125611 

1104 

1104 

100.0 

89.0 

100.0 

122 

0 

3. 3. 3. 2. 3 

DISC  FILE  TRANSFER 

125611 

160 

106 

66.2 

93.0 

100.0 

-42 

54 

TOTALS: 

32202 

2391  1 

74.3 

82.7 

91.0 

-2718 

5384 

Figure  10.  Milestone  Summary  Report 


The  Cost  Performance  Summary  report  provides  effect,  a  work  order  represents  the  allocated 
a  tally  of  the  milestone  matrix  values  In  terms  budget  for  a  particular  design  effort,  while  the 
of  the  assigned  work  order  numbers  and  displays  variance  represents  the  additional  effort 
the  variances  associated  with  each  tally.  The  required  or  surplus  effort  expended  in  meeting 
variances  Identify  the  difference  In  expected  and  the  budgeted  milestone.  Figure  11  illustrates  a 
actual  design  completion  for  a  work  order.  In  sample  Cost  Performance  report. 
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POINT  NUMBER  STATUS 


CHARGE 

TOTAL 

POINTS 

PER  CENT 

01/01/83 

BUDGET 

01/01/83 

EXPECTED 

02/01/83 
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POINTS 
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POINTS 

TO  DATE 

COMPLETE 

PER  CENT 

POINTS 
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REQUIRED 
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0 

n 
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.0 

0 

.0 

0 
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125521 

0 

0 

.0 

.0 

n 

.0 

n 

INACTIVE 

125522 

0 

0 

.0 

.0 

0 

.0 

0 

INACTIVE. 

125611 

10386 

8239 

79.3 

92.1 

9570 

97.9 

1331 

TROUBLE 

125621 

660 

256 

38.8 

100.0 

660 

100.0 

404 

TROUBLE 

125622 

0 

0 

.0 

.0 

0 

.0 

n 

INACTIVE 

125632 

n 

0 

.0 

.0 

n 

.0 

0 

INACTIVE 

125634 

0 

0 

.0 

.0 

n 

.0 

n 

INACTIVE 

125641 

21156 

15415 

72.9 

77.5 

16399 

87.3 

983 

TROUBLE 

125711 

0 

0 

.0 

.0 

0 

.0 

0 

INACTIVE 

SURPLUS  POINTS: 

0 

TOTALS:  12202  23911  74.3  82.7  26629  91.0  2718  TROUBLE 

Figure  11.  Cost  Performance  Summary  Report 


In  addition  to  the  standard  reports  generated 
by  the  AAIs  program,  the  manager  can  direct  the 
program  to  accumulate  milestone  statistics  over 
auditing  periods  to  graphically  construct  prog¬ 
ress  plots.  This  accumulation  Is  accomplished  by 
the  use  of  the  history  files  described  in  the 
previous  section.  These  progress  plots  have  been 
effectively  presented  to  the  contract  sponsor  by 
the  20B5  management  during  periodic  Program 


As  shown  previously  in  Figure  2,  each  func¬ 
tion  hierarchy  must  be  established  when  the 
design  is  initiated.  The  hierarchy  is  subse¬ 
quently  maintained  in  a  file  on  the  computer 
storage  media.  Note  that  module  values  are 
specified  according  to  the  level  of  complexity. 
It  should  be  recognized  that  the  status  reports 
will  Incorporate  any  design  changes  as  performed 
on  the  appropriate  data  files.  However,  the 


Progress  Reviews  (PPRs).  One  such  plot  is 
presented  In  Figure  12. 

AAIS  Inputs:  Control  Data 

Software  managers  must  define  seven  (7)  input 
data  sets  to  drive  the  AAIS  program.  These  data 
sets  are  as  follows: 

(1)  Baseline  starting  dates 

(2)  Software  work  order  numbers 

(3)  Plotting  options 

(4)  Function  hierarchies 

(5)  Function  milestone  weights 

(6)  Function  milestone  dates 

(7)  Module  weights. 

Data  Input  sets  (1),  (2)  and  (4)  apply  to  the 
entire  software  effort  and  are  specified  for  each 
function  hierarchy  defined.  The  remaining  input 
data  sets  are  unique  to  each  function  hierarchy. 


manager  must  understand  that  this  flexibility 
allows  for  a  rolling  baseline  for  audits.  The 
particular  function  or  functions  audited  are 
specified  when  performing  an  audit. 

AAIS  Processing 

AAIS  processing  Is  given  by  the  functional 
flow  diagram  presented  in  Figure  13.  For  Device 
20B5,  a  full  audit  Involving  approximately  800 
modules  requires  about  43  minutes  of  computer 
execution  and  report  generation  time.  The  entire 
process  does  not  interfere  with  software  develop¬ 
ment  activities. 

Organizing  the  control  Inputs  presented  in 
the  previous  section  into  files  on  the  computer 
storage  media  requires  approximately  one  (1) 
man-month  of  effort.  These  files  are  subse¬ 
quently  updated  by  Individual  designers  as 
software  designs  are  expanded  or  modified.  An 
additional  man-month  of  effort  Is  required  to 
produce  the  AAIS  program  in  the  desired  high 
level  language. 


□  o 


Summary 

The  AAIS  procedure  performs  audits  of  the 
20B5  software  development  library  upon  demand. 
The  audit  Information  provides  managers  with  an 
improved  capability  to  control  software  develop¬ 
ment  activities  and  to  improve  projections  for 
completion.  The  system  is  adaptable  to  other 
projects  if  similar  organization  and  procedures 
are  applied. 
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Figure  13.  The  AAIS  Program  Functional  Flow 


